On 09/27/2012 12:19 AM, Kenneth Graunke wrote:
On 09/26/2012 10:55 PM, Matt Turner wrote:
On Wed, Sep 26, 2012 at 10:47 PM, Kenneth Graunke<kenn...@whitecape.org>  wrote:
On 09/26/2012 04:09 PM, Matt Turner wrote:
On Wed, Sep 26, 2012 at 2:50 PM, Török Edwin wrote:
Another issue is that the yacc-generated files are not removed by 'make clean',
but thats probably on purpose (do the generated files get shipped in the 
release tarball?),
I should've run 'make distclean'.

Specifically program_parse.c and program_lexer.c, right?

I'm not sure whether yacc- and lex-generated files should be removed
by make clean. I'm inconsistent about this -- I don't remove the
program files, but I do remove the glsl/glcpp files on make clean.

However, they should be shipped in the tarball.

I would argue that 'make clean' should remove them.  In my mind, the
purpose of 'make clean' is to remove any files generated as part of the
build process (or at least the 'make' part of it), which includes
generated source code.

Including them in the tarballs seems sensible.

Imagine unpacking the tarball (which has the generated code which
doesn't require flex and bison, at least it shouldn't), running make
clean (which removes the code) and then trying to rebuild. :)

I'm not sure it matters much, and there are multiple ways to avoid
this. I just haven't though about what is actually sensible.

Yeah.  Honestly, putting generated code in the tarballs and making the
build system deal with both the tarball/non-tarball case has always
seemed like a pain.  I'd almost rather just see it be consistent...

It does avoid having to install bison and flex.  (It doesn't avoid
python 2.x.)  Developers have them already, and they're pretty common.
For most distros, it's probably just a matter of flagging the build
dependency in the package description and pointing tools at it.  Is this
really useful for anybody?

Lex and yacc are a bit of a PITA on Windows. Building the tarballs on Windows would be a little easier if the lex/yacc-generated were included.

-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to