On 28/02/15 20:42, Matt Turner wrote: > On Sat, Feb 28, 2015 at 3:10 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> On 27/02/15 17:42, Matt Turner wrote: >>> For flex and bison, we check if a generated source file exists, which >>> is probably a good idea. That way configure will fail in a git >>> checkout if you don't have python. >>> >> Checking for the presence of one auto-generated file does not sound like >> a great idea imho. What happens if any of the other files is not present >> - should we keep the whole list in configure.ac ? Keeping the list in >> sync seems quite error prone. > > I copied the check-for-a-file pattern from libxkbcommon at the > recommendation of Gaetan Nadon more than three years ago, and as far > as I'm aware it's worked just fine. That's not to say that it's > perfect, but claiming something that's been working fine for three > years is "not a great idea" without offering a suggestion is a bit off > putting. > There was a suggestion below which admittedly is quite a ugly one. From a quick look at libxkbcommon, there has been a case where the file was renamed, and the hunk was not updated.
That said I think that trying to keep the list in sync is perhaps the best thing we can do. The alternative solution from #autotools was to just warn when python/lex/etc. is missing and fail at build stage. > > Maybe I've misunderstood how this patch works. From the sound of > "without Python it is going to fail anyway because Python is not > present when trying to autogenerate the files" it seems that we're > okay with not checking for mako if Python isn't present because > running make is going to fail anyway? > > That doesn't sound like what we want -- it's configure's job to > determine if we have the necessary dependencies for make to succeed. > To sum it all up, how does this sound: * Change ax_check_python_mako_module.m4 to set a variable, rather than error out. This way we can have a bit more flexibility in configure.ac * python is not found and X is not generated - error(you need python for X) * python/mako is not found and Y is not generated - error(you need python/mako for Y). Keeping the checks and error messages for python and mako separate of course. > I'll think about this some more. > >> A hacky alternative is to set the variable (BISON/LEX/PYTHON2) to >> something like `echo "Missing XXX dependency" && return 1` when empty. >> Yet that looks quite nasty, plus it shows rather late in the build >> process :\ >> >>> I have in my todo list to add some remaining source files generated by >>> python to the autotools distribution. After we commit some version of >>> this patch, Emil or I should make sure that all the python-generated >>> code is included in the tarball. >>> >> I was under the impression that we already do, but I will double-check. >> >> >> On a mildly related note: >> For anyone that missed it Ken voiced concerns over shipping the >> lex/bison generated files. Main idea is that as(if) security bugs are >> found and fixed in those products, mesa has been released with such >> vulnerable files. >> I can see his point, and I tend to agree with him. How do others feel on >> the topic ? > > Someone concerned should talk to the automake/bison/flex upstreams and > see what they think. It is of course automake that adds the generated > code to the distribution. > > We're certainly not the only project shipping code generated by flex and > bison. > Ack. Just wanted to point out for anyone that was not in #dri-devel. Perhaps we can carry on in a separate thread if/when needed. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
