[Mesa-dev] [PATCH] glapi: Fix incorrect enum value.

[Paul Berry]

On 22 February 2012 16:06, Chad Versace <chad.versace at linux.intel.com>wrote:

> 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 <idr at freedesktop.org
> >> <mailto:idr at 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.romanick at intel.com
> >>     <mailto:ian.d.romanick at 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120222/cc9fce78/attachment.html>