On 02/22/2012 02:22 PM, Ian Romanick wrote:
> On 02/22/2012 02:17 PM, Paul Berry wrote:
>> On 22 February 2012 13:52, Ian Romanick <i...@freedesktop.org
>> <mailto:i...@freedesktop.org>> wrote:
>>
>>     On 02/22/2012 01:41 PM, Paul Berry wrote:
>>
>>           From
>>         http://www.opengl.org/__registry/specs/ARB/seamless___cube_map.txt
>>         <http://www.opengl.org/registry/specs/ARB/seamless_cube_map.txt>:
>>
>>              Accepted by the<cap>  parameter of Enable, Disable and
>>         IsEnabled,
>>              and by the<pname>  parameter of GetBooleanv, GetIntegerv,
>>         GetFloatv
>>              and GetDoublev:
>>
>>              TEXTURE_CUBE_MAP_SEAMLESS                   0x884F
>>
>>
>>     Oops.  That was my typo.  You'll also have to regenerate the various
>>     files that depend on the XML definitions.  I think this change
>>     should only cause changes in src/mesa/main/enums.c.
>>
>>     Reviewed-by: Ian Romanick <ian.d.roman...@intel.com
>>     <mailto:ian.d.roman...@intel.com>>
>>
>>
>> Oops.  I didn't realize that those files weren't built automatically.
>> I'll send an updated patch.
> 
> Dear god, no!  The patch will be huge.
 
>> Is there any good reason why we don't automatically generate files like
>> enum.c as part of the mesa build process?  The comment at the top of
>> src/mapi/glapi/gen/Makefile says "This file isn't used during a normal
>> compilation since we don't want to require Python in order to compile
>> Mesa."  But I don't think that makes sense anymore, because Python is
>> required to build files like src/mapi/es2api/glapi_mapi_tmp.h, as well
>> as some files in src/glsl.
>>
>> In point of fact, it seems really strange that a file like
>> src/mapi/es2api/glapi_mapi_tmp.h is autogenerated during the build
>> process, but src/mesa/main/enums.c isn't, since both files are built
>> from the same set of xml sources.
> 
> A couple reasons:

I really want to see all *build* artifacts removed from Mesa's *source* 
control. I recall the
pain of having the bison and flex output managed by git, and I don't like 
continuing that fallacy.

> 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.

Wouldn't `git log *.xml *.py` also alert you that the generated headers have 
changed?
> 
> 2. Changes to the XML files frequently precipitate changes to files in the 
> xserver.  There's no way to automatically handle that.

I don't understand how 2 affects this discussion. Is it that the xserver build 
relies on these generated headers? If so, then
we can move the generated headers to the xserver repo and merrily remove these 
build artifacts from Mesa's source control.
Afterwards, it would be the xserver's devs responsibility to manually update 
their headers, or fix their makefiles to gen them
at build time.

> 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.

$ cd src/mapi/glapi/gen
$ make mesa
real    0m5.634s

I don't think an adding 5 seconds to a clean build is cause for concern if the 
addition allows us
to remove build artifacts from source control.

----
Chad Versace
chad.vers...@linux.intel.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to