On 22 February 2012 16:06, Chad Versace <span dir="ltr"><<a href="mailto:chad.versace@linux.intel.com">chad.versace@linux.intel.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 02/22/2012 02:22 PM, Ian Romanick wrote:<br>
> On 02/22/2012 02:17 PM, Paul Berry wrote:<br>
>> On 22 February 2012 13:52, Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a><br>
>> <mailto:<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>>> wrote:<br>
>><br>
>> On 02/22/2012 01:41 PM, Paul Berry wrote:<br>
>><br>
>> From<br>
>> <a href="http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt" target="_blank">http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt</a><br>
>> <<a href="http://www.opengl.org/registry/specs/ARB/seamless_cube_map.txt" target="_blank">http://www.opengl.org/registry/specs/ARB/seamless_cube_map.txt</a>>:<br>
>><br>
>> Accepted by the<cap> parameter of Enable, Disable and<br>
>> IsEnabled,<br>
>> and by the<pname> parameter of GetBooleanv, GetIntegerv,<br>
>> GetFloatv<br>
>> and GetDoublev:<br>
>><br>
>> TEXTURE_CUBE_MAP_SEAMLESS 0x884F<br>
>><br>
>><br>
>> Oops. That was my typo. You'll also have to regenerate the various<br>
>> files that depend on the XML definitions. I think this change<br>
>> should only cause changes in src/mesa/main/enums.c.<br>
>><br>
>> Reviewed-by: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a><br>
>> <mailto:<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>>><br>
>><br>
>><br>
>> Oops. I didn't realize that those files weren't built automatically.<br>
>> I'll send an updated patch.<br>
><br>
> Dear god, no! The patch will be huge.<br>
<br>
>> Is there any good reason why we don't automatically generate files like<br>
>> enum.c as part of the mesa build process? The comment at the top of<br>
>> src/mapi/glapi/gen/Makefile says "This file isn't used during a normal<br>
>> compilation since we don't want to require Python in order to compile<br>
>> Mesa." But I don't think that makes sense anymore, because Python is<br>
>> required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well<br>
>> as some files in src/glsl.<br>
>><br>
>> In point of fact, it seems really strange that a file like<br>
>> src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build<br>
>> process, but src/mesa/main/enums.c isn't, since both files are built<br>
>> from the same set of xml sources.<br>
><br>
> A couple reasons:<br>
<br>
</div></div>I really want to see all *build* artifacts removed from Mesa's *source* control. I recall the<br>
pain of having the bison and flex output managed by git, and I don't like continuing that fallacy.<br>
<div class="im"><br>
> 1. The generated files really, really, really should be in git so that accidental changes will be noticed. This has bitten us a couple times.<br>
<br>
</div>Wouldn't `git log *.xml *.py` also alert you that the generated headers have changed?<br>
<div class="im">><br>
> 2. Changes to the XML files frequently precipitate changes to files in the xserver. There's no way to automatically handle that.<br>
<br>
</div>I don't understand how 2 affects this discussion. Is it that the xserver build relies on these generated headers? If so, then<br>
we can move the generated headers to the xserver repo and merrily remove these build artifacts from Mesa's source control.<br>
Afterwards, it would be the xserver's devs responsibility to manually update their headers, or fix their makefiles to gen them<br>
at build time.<br>
<div class="im"><br>
> 3. Several of the scripts take a really, really long time to run. I'm not eager to add a few minutes to my clean-build times.<br>
<br>
</div>$ cd src/mapi/glapi/gen<br>
$ make mesa<br>
real 0m5.634s<br>
<br>
I don't think an adding 5 seconds to a clean build is cause for concern if the addition allows us<br>
to remove build artifacts from source control.<br></blockquote><div><br>I agree with this. In my experience, including build outputs in source control is nearly always a mistake; as a rule, I'd rather exclude build artifacts from source control except in situations where there is no feasible alternative. IMHO this doesn't seem like one of those situations.<br>
</div></div>