Re: [uml-devel] RFC: Shouldn't "./linux --version" always print the the git commit id

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dne 26.10.2013 12:06, Toralf Förster napsal(a):
> On 10/26/2013 09:56 AM, Geert Uytterhoeven wrote:
>> On Fri, Oct 25, 2013 at 11:19 PM, Toralf Förster <toralf.foerster@xxxxxx> wrote:
>>> $ ./linux --version
>>> 3.11.0
>>
>> If there are no additional commits on top of the tag, no number and commit
>> ID are printed. I guess the rationale is that tags are global, hence present
>> in all clones, so there's no need to tell what commit ID the tag corresponds
>> to.
>>
>>> which correlates to
>>>
>>> $ git describe
>>> v3.11
>>>
>>> $ git describe --long
>>> v3.11-0-g6e46645
>>
>> This is not UML-specific. If you want to change this, you have to involve
>> the kbuild people (CC added).
>>
> Well, the reationale behind my idea comes from the (stupid) logic of one
> of my bisect scripts. I used there the commit id derived from the UML
> linux exe as a suffix for gdb back trace files created during the bisect
> process.
> Sure - logic can be easily adapted and was in the mean while.
> But IMO it would be more stringent to have always the commit id
> presented in the version string for similar cases.

You define your own versioning scheme if you build with
CONFIG_LOCALVERSION_AUTO=n and define LOCALVERSION yourself. E.g.

echo "-g$(git rev-parse --short HEAD)" >localversion-git

or set it in kconfig or on the make commandline.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux