On 04/24/2013 04:11 PM, Paul Berry wrote:
On 23 April 2013 21:22, Chad Versace <chad.vers...@linux.intel.com <mailto:chad.vers...@linux.intel.com>> wrote:On 04/23/2013 09:19 PM, Eric Anholt wrote: Chad Versace <chad.vers...@linux.intel.com <mailto:chad.vers...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
