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

[Emil Velikov]

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.
> 
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