From: Mathis Ahrens <Mathis.Ahrens@gmx.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [2.6.16-rc6] CONFIG_LOCALVERSION_AUTO
Date: Fri, 17 Mar 2006 00:49:15 +0100 [thread overview]
Message-ID: <4419F97B.5090301@gmx.de> (raw)
In-Reply-To: <20060316203400.GA24008@mars.ravnborg.org>
Sam Ravnborg wrote:
> On Wed, Mar 15, 2006 at 05:47:51AM +0100, Mathis Ahrens wrote:
>
>> 1.
>> Semantics of LOCALVERSION are confusing and probably buggy.
>> [...]
>>
> This is a bug.
> I will fix that for 2.6.17.
>
Cool, thanks.
>> 2.
>> "make kernelrelease" does not imply "make .kernelrelease", it only
>> does cat the file .kernelrelease (or shows an error if it's not there).
>>
Oh, I notice that I have been dumb here. Of course `make kernelrelease`
should not depend on `make .kernelrelease` or alter .kernelrelease in any
way.
>> This leads to the following IMHO slightly irritating behaviour
>> $ echo "LV1" > localversion
>> $ make kernelrelease
>> 2.6.16-rc6LV1
>> $ echo "LV2" > localversion
>> $ make kernelrelease
>> 2.6.16-rc6LV1
>>
>> Is there a reason for this?
>>
> make kernelrelase shall work in both a read-only environment and shall
> avoid modifying files when run as another user.
> So the simple measure was to error out only if .kernelrelease was
> missing.
>
But then - for this I would use `cat .kernelrelease` ?
> The trick here seems to print $(KERNELVERSION)$(localver-full)
> but only if .kernelrelease is present.
> On the other hand if .kernelrelase and $(KERNELVERSION)$(localver-full)
> differ then what to print.
> The kernelrelease of the kernel or how it is configured?
>
Yes, these may be different, and both are interesting:
1. What name would I get if I started building now.
2. Assuming I did not modify anything since the last build, what was it
named?
> echo -sam > locelversion does NOT change the kernel.
> The kernelrealse of the kernel is only changed after running 'make'.
> And this is what we want to see - the kernelrelase of the kernel, not
> what happes to be stored in a file after the kernel was compiled.
>
Right. Only I get this also with `cat .kernelrelease`.
That's why my intuition said, `make kernelrelease` probably prints the
string
that *would* be appended, based on all the knowledge in the Makefile.
After all, this is interesting, since that composition is not trivial,
and the
logic is inside the Makefile.
Maybe this could be made another target?
`make upcomingrelease` (-;
Cheers,
Mathis
prev parent reply other threads:[~2006-03-16 23:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-15 4:47 [2.6.16-rc6] CONFIG_LOCALVERSION_AUTO Mathis Ahrens
2006-03-16 20:20 ` [PATCH] Makefile: localversion fix (was: [2.6.16-rc6] CONFIG_LOCALVERSION_AUTO) Mathis Ahrens
2006-03-16 20:34 ` [2.6.16-rc6] CONFIG_LOCALVERSION_AUTO Sam Ravnborg
2006-03-16 23:49 ` Mathis Ahrens [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4419F97B.5090301@gmx.de \
--to=mathis.ahrens@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox