[Mesa-dev] [RFC] configure.ac: Don't check for python mako module if python is not installed

[Samuel Iglesias Gonsálvez]

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.velikov at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150302/cb62661e/attachment.sig>