fixing the recurring Mesa build problem

Michel Dänzer michel at tungstengraphics.com
Mon Nov 20 04:09:27 PST 2006


On Sun, 2006-11-19 at 10:42 -0800, Dan Nicholson wrote:
> On 11/19/06, Michel Dänzer <michel at tungstengraphics.com> wrote:
> >
> > As automake now doesn't know about the contents of the sources files, the
> > nodist_*_la_OBJECTS variables in its output end up not containing the
> > symlinked source files, so they don't get compiled. I tried overriding
> > nodist_*_la_OBJECTS and *_la_DEPENDENCIES in Makefile.am without
> > success. Any ideas for this anyone?
> 
> Oh, wow, total showstopper. I hadn't even thought about the libtool
> objects. Now I'm seeing exactly what you're seeing. This is really a
> difficult problem to attack because, with the existing setup, the Mesa
> sources need to be know at dist time and at configure time. 

Actually, they only really need to be known at build time. The problem
is how to have automake use an external list of files at that time.


> Here's another ugly fix that might improve the situation slightly. At
> least people would have a defined path forward if their Mesa sources
> aren't the same as the developer's Mesa sources. The path to Mesa is
> given to autogen.sh. This goes through and creates a static list of
> the Mesa sources from the "sources" files in Mesa. Then automake runs
> with these static lists included and can generate the
> _la_OBJECTS/DEPENDENCIES.
> 
> At configure time, the Mesa tree is pointed to again and the symlink
> script is run. Assuming that the Mesa tree at dist and at configure
> are different (say a file changed names), make is going to bomb. Then
> you could at least just run autogen.sh again pointing to your Mesa
> tree, the _la_SOURCES would be updated to what's in your tree, and
> hopefully things would work.

One problem with this is that autogen.sh isn't (and shouldn't be)
distributed in tarballs.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer




More information about the xorg mailing list