On Sun, 2015-03-01 at 12:38 +0000, Emil Velikov wrote: > 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. > >
Yeah, this is one of the reasons I tagged it as RFC, this is a workaround that could be improved or trigger a discussion about a better solution :-) > 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 like it. If Matt agrees, I will modify ax_check_python_mako_module.m4 to set a variable. > > 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. > I am not an autotools expert but if there is anything I can do to help, please do not hesitate to let me know. Sam
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
