| To: | Eric Sandeen <sandeen@xxxxxxx> |
|---|---|
| Subject: | Re: xfs: Makefile-linux-2.6 => Makefile? |
| From: | Sam Ravnborg <sam@xxxxxxxxxxxx> |
| Date: | Mon, 9 Jan 2006 22:45:44 +0100 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <43C2D45B.2050704@xxxxxxx> |
| References: | <20060109164214.GA10367@xxxxxxxxxxxxxxxxx> <20060109164611.GA1382@xxxxxxxxxxxxx> <43C2CFBD.8040901@xxxxxxx> <20060109212005.GC14477@xxxxxxxxxxxxxxxxx> <43C2D45B.2050704@xxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.11 |
On Mon, Jan 09, 2006 at 03:23:39PM -0600, Eric Sandeen wrote:
> codebases.
>
> But it seems useful for projects outside the kernel which would like to
> know which kernel they are building against, as far as the build system
> goes. I've seen a few drivers out there that try to keep building for both
> 2.4 & 2.6.
>
> I guess for 2.4 & 2.6, the same can be accomplished by using Makefile and
> Kbuild for 2.4 and 2.6....
Good point. External modules slipped my mind when I did this change.
We have today:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 15
EXTRAVERSION =
EXTRAVERSION will soon become -rc1
No sane driver will check for more than VERISON, PATCHLEVEL, SUBLEVEL.
xfs for once only used VERSION, PATCHLEVEL.
googling a little gave lot's of very ugly examples how it can be done
using grep, perl etc. So there is a legitim need for the variable
anyway.
So I will re-export VERISON, PATCHLEVEL, SUBLEVEL.
Sam
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: xfs: Makefile-linux-2.6 => Makefile?, Eric Sandeen |
|---|---|
| Next by Date: | TAKE 904196 - Merge up to 2.6.15, Nathan Scott |
| Previous by Thread: | Re: xfs: Makefile-linux-2.6 => Makefile?, Eric Sandeen |
| Next by Thread: | Re: xfs: Makefile-linux-2.6 => Makefile?, Andrew Morton |
| Indexes: | [Date] [Thread] [Top] [All Lists] |