[Mesa-dev] [PATCH] mesa: Allow custom text to be inserted in version string at buildtime

[Ian Romanick]

On 04/24/2013 04:11 PM, Paul Berry wrote:
> On 23 April 2013 21:22, Chad Versace <chad.versace at linux.intel.com
> <mailto:chad.versace at linux.intel.com>> wrote:
>
>     On 04/23/2013 09:19 PM, Eric Anholt wrote:
>
>         Chad Versace <chad.versace at linux.intel.com
>         <mailto:chad.versace at linux.intel.com>> writes:
>
>             On 04/23/2013 06:19 AM, Ian Romanick wrote:
>
>                 On 04/23/2013 03:28 AM, Chad Versace wrote:
>
>                     This allows maintainers/packagers/testers to tag the
>                     build with
>                     information that will be reported by GL_VERSION.
>
>                     If the environemt variable or make variable
>                     MESA_VERSION_STRING_EXTRA is
>
>                             environment
>
>                     set, then its values will appear in the GL_VERSION
>                     string immediately
>                     after "Mesa X.Y" and before "(git-xxxxxxx)".
>
>                     This patch implements supports
>                     MESA_VERSION_STRING_EXTRA only for Android.
>                     Other build systems are left as an excercise.
>
>
>                 Why is this useful?
>
>
>             The commit message says why: it allows packagers to tag the
>             build with info
>             that gets reported by GL_VERSION.
>
>             How is it used now? The Mesa that gets shipped bi-weekly
>             internally in Intel
>             for Android is not a snapshot of master nor of any stable
>             branch. Yet, that
>             snapshot of Mesa is "official", as far as Intel's Android
>             efforts are concerned.
>             The Android team is using this patch to inject into
>             GL_VERSION the name of the bi-weekly
>             Android release.
>
>             Without this patch, you may one day get a bug report that
>             says: "This bug exists
>             in Mesa 9.2-devel (git-xxxxxxx)". Then, you will search for
>             the git sha1, and
>             unable to find it, yell bloody murder and close the bug as
>             invalid. With this
>             patch, though, you may get a bug report that says: "This bug
>             exists in
>             Mesa 9.2-devel otc-android-2013-04-23-blah (git-xxxxxxx)",
>             and then you
>             will know how to find that Mesa.
>
>
>         So along with a useless sha1, I have a useless date that doesn't
>         tell me
>         what Mesa it was actually based off of.  I say this having tried to
>         figure out what Mesa actually got used in one of these android
>         tests and
>         failed.
>
>
>     Rather than jabs and parrying, let's turn this conversation into a
>     constructive one. If you receive a
>     communication about Mesa on Android, how do you want the Mesa version
>     communicated to you so that you can fetch and then inspect that same
>     Mesa?
>
>     Keep in mind that the Android Mesa tree is regularly rebased onto
>     master, so  the shas
>     are not as useful as you would hope. Also know that we have git tags for
>     the "useless" dates if you know where to fetch from.
>
> Would it be helpful to use "git describe --long" to generate the git
> portion of the GL_version string?  That's essentially what the Linux
> kernel build uses it for this kind of purpose.  It generates a
> generates a string like this: "mesa-9.1-9-ga5c79b7", where "mesa-9.1" is
> the most recent annotated tag accessible from HEAD, "9" is the number of
> commits between that tag and HEAD, and "a5c79b7" is the SHA of HEAD.
>
> If we do this we might want to start making annotated tags of master
> every now and again--currently the most recent annotated tag accessible
> from master is a tag called "snb-magic" from November 2010.

Regardless of what happens with the rest of this, that is a fine idea. 
I'd be in favor of tagging master each time we're going to make a stable 
branch.  I know GIT can figure out what the common root of two branches, 
but it would be a lot easier to just do 'git log pre-9.1..' to see all 
the commits since the branch was created.