[Mesa-dev] [PATCH 20/20] tests/glx: Add unit tests for GLX_ARB_create_context GLX protocol

[Dan Nicholson]

2012/1/4 Ian Romanick <idr at freedesktop.org>:
> On 01/04/2012 11:05 AM, Michel Dänzer wrote:
>>
>> On Mit, 2012-01-04 at 10:56 -0800, Ian Romanick wrote:
>>>
>>> On 01/04/2012 10:55 AM, Daniel Stone wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 4 January 2012 18:45, Ian Romanick<idr at freedesktop.org>   wrote:
>>>>>
>>>>> Okay, I looked back at your build output, and I think I see the
>>>>> problem:
>>>>>
>>>>>   * econf: updating Mesa-9999/bin/config.sub with
>>>>> /usr/share/gnuconfig/config.sub
>>>>>   * econf: updating Mesa-9999/bin/config.guess with
>>>>> /usr/share/gnuconfig/config.guess
>>>>> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
>>>>> [...]
>>>>>
>>>>> Since it's a raw GIT tree, this should be 'autogen.sh' instead of
>>>>> 'configure'.  The Makefile.in files are generated by autoreconf (run by
>>>>> autogen.sh) and consumed by configure.  Since they haven't been
>>>>> generated,
>>>>> configure can't find them and gets angry.  The ebuild scripts need to
>>>>> either
>>>>> run ./autogen.sh or run 'autoreconf -v --install' before running
>>>>> configure.
>>>>>
>>>>> I bet that will fix it, and I bet that's why only Gentoo users are
>>>>> still
>>>>> having problems.  Can you give that a try?
>>>>
>>>>
>>>> See immediately before that:
>>>>>>>
>>>>>>> Preparing source in
>>>>>>> /var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999 ...
>>>>
>>>> Running eautoreconf in
>>>> '/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999' ...
>>>> Running aclocal ... [ok]
>>>> Running autoconf ... [ok]
>>>>>>>
>>>>>>> Source prepared.
>>>
>>>
>>> Okay.  I give up.  I have no clue why it's not working.  Patches welcome.
>>> :(
>>
>>
>> It's not running automake (just like the Mesa toplevel Makefile
>> isn't...).
>
>
> Right... autoreconf does aclocal, autoconf, and automake all in one shot.
>  That makes sense.
>
> About adding automake to the toplevel Makefile, where should that go? It
> seems like adding it to 'default' or similar will break the non-autotool
> builds.  Doing that so close before a release seems mean. Since the automake
> business is only necessary for 'make check', would putting it in the 'check'
> target be sufficient?

Hi Ian,

I'm a little busy at the moment, but just wanted to mention that the
automake integration looks OK on a first glance. The problems being
faced here seems to be gentoo's "eautoreconf" script. I'm guessing
that since the toplevel Makefile is not Makefile.am, it doesn't think
it needs to run automake. That's lame and it's the whole reason the
regular autoreconf script exists in the first place. It can tell that
you added AM_INIT_AUTOMAKE to configure.ac and therefore it needs to
run automake. There's no "automake" to add in the toplevel Makefile.
autogen.sh/autoreconf will do the right thing.

That said, you could definitely hack in these changes without pulling
in automake.

--
Dan