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

Paul Berry stereotype441 at gmail.com
Wed Apr 24 07:11:44 PDT 2013


On 23 April 2013 21:22, Chad Versace <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> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130424/969dddd1/attachment.html>


More information about the mesa-dev mailing list