diff mbox

mesa3d autoreconfigure problem

Message ID CAJpxd07aYbSX=Lxc48y+3=GvTp5rujcZNPfp+gOaX_6bf5Z-jA@mail.gmail.com
State Not Applicable
Headers show

Commit Message

Bryce Schober Jan. 3, 2014, 6:54 p.m. UTC 
The autoreconfigure step for mesa3d is failing for me, because the
mesa_version expanded into the new configure script is somehow getting
the value "make2: Entering directory
`<outdir>/build/mesa3d-7.10.3'7.10.3make2: Leaving directory
`<outdir>/build/mesa3d-7.10.3'".

I'll start this off by saying that I'm abusing buildroot, and my
particular abuse is known to be one root cause of the problem. That
said, I'm guessing that the expertise on this list could probably see
through to a workaround fairly easily.

The following patch to mesa's configure.ac does actually work around
the problem, but seems to me like a pretty ugly hack:

bin/version.mk version`])])

I hope that the following description of my particular abuse isn't
necessary to suggest a better workaround, and you can stop reading
here. ;-)

My abuse of buildroot is that this particular output directory is a
what I'll call an "overlay" build. Its host and staging dirs are
symlinks into those of a previous "base" output directory. Its stamps
& target directories are full copies of those from the base. Its build
directory is pre-populated with symlinks into the build sub-dirs of
the base. This has the net effect of building a target filesystem that
is a superset of the base, without having to rebuild everything (and
get the inevitable annoying embedded time-stamp differences in
binaries).

<><  <><  <><
Bryce Schober

Comments

Bryce Schober Jan. 7, 2014, 6:40 p.m. UTC | #1 
This problem is much, much more generic than I first thought:

The autoreconfigure step of mesa3d will *always* fail if buildroot's make
is ever called with from another directory, using the -C option. It looks
like the mesa3d package's configure.ac is just not meant to handle this
situation, at least not in the context of buildroot's infrastructure.

Their configure.ac uses this faulty dynamic method through
8.0<http://cgit.freedesktop.org/mesa/mesa/tree/configure.ac?h=8.0>.
In 9.x <http://cgit.freedesktop.org/mesa/mesa/tree/configure.ac?h=9.2>,
they switched to a static version number. Then in
10.0<http://cgit.freedesktop.org/mesa/mesa/tree/configure.ac>,
they switched to a different method, including it from elsewhere.

What's the best way forward here? I know next to nothing about autoconf...

<><  <><  <><
Bryce Schober
Bernd Kuhls Jan. 7, 2014, 7:02 p.m. UTC | #2 
Bryce Schober <bryce.schober@gmail.com>
wrote in
news:CAJpxd07F14_pk7k+AEqaoUAjv_QgB1uaxnoHHtO5twd3nSKsRw@mail.gmail.com: 

> What's the best way forward here? I know next to nothing about
> autoconf... 

Hi,

efforts are currently underway to update mesa3d to 9.x and later 10.x, so it 
would be a good idea to just sit and wait ;)

Regards, Bernd
diff mbox

Patch

--- mesa3d-7.10.3/configure.ac.old 2014-01-03 10:28:31.000000000 -0800
+++ mesa3d-7.10.3/configure.ac 2014-01-03 10:47:28.000000000 -0800
@@ -4,7 +4,7 @@ 

 dnl Versioning - scrape the version from configs/default
 m4_define([mesa_version],
-    [m4_esyscmd([${MAKE-make} -s -f bin/version.mk version | tr -d
'\n' | tr -d '\r'])])
+    [m4_esyscmd([make -s -f bin/version.mk version | tr -d '\n' | tr
-d '\r'])])
 m4_ifval(mesa_version,,
     [m4_fatal([Failed to get the Mesa version from `make -f