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? If it is, then sure, it's totally solvable. If it's not, well... _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
