Can somebody hit the Mesa maintainers with the clue-stick, please?

I’ve been waiting a while for the release of Mesa 7.0.2 as 7.0.1 doesn’t include support for the G33 chipset in my motherboard, and as a result I’ve been running with a git snapshot, something which always makes me a little uneasy. It’s finally been released, but alas when I build (at “make install” specifically) I get an error:

make[2]: Entering directory `/usr/src/Mesa-7.0.2/src/glw’
make[2]: *** No rule to make target `glw.pc.in’, needed by `glw.pc’. Stop.
make[2]: Leaving directory `/usr/src/Mesa-7.0.2/src/glw’
make[1]: *** [install] Error 1
make[1]: Leaving directory `/usr/src/Mesa-7.0.2/src’
make: *** [install] Error 1

The problem is quite basic; The “glw.pc.in” file is MIA because it hasn’t been included in the source tarball. This is in itself fairly annoying but I take issue for two reaons: firstly, this error should have happened during the initial “make” and not “make install”. Secondly, obviously nobody tested whether Mesa could be built and installed from the tarball before it was officially released. This latter is really stupid.

On the plus side, with the 7.0.2 release Mesa finally has support for “make DESTDIR=… install”.

Edit 19/11/07: This is what “glw.pc.in” is supposed to look like. There doesn’t seem to be a directly downloadable version.

Edit 12/01/08: Entry in the bug database. Fixed for 7.0.3 apparently (not yet released).

Edit 06/04/08: Mesa 7.0.3 has finally been released (after 5 months), and yes, it fixes this problem. It should not have taken 5 months to fix this problem. Not being able to “make install” is serious.

Advertisements

3 thoughts on “Can somebody hit the Mesa maintainers with the clue-stick, please?

  1. I just ran into that very same problem and you’ll be pleased to know using “No rule to make target `glw.pc.in’, needed by `glw.pc’. Stop.” as a search term makes your blog the #1 hit on google. At least I now know its not due to me running a pure 64bit environment with glibc-2.7, binutils-2.18 and 2.6.23.8.

    Sigh.

  2. Ran into this myself, and found your page via google. I just downloaded the 7.0.2 sources this week, so they haven’t even bothered to update the 7.0.2 sources, or turn 7.0.3 as “something that will compile.”

    The mesa build system is pretty kludgy anyway. And DESTDIR has always been there – but now it’s slightly different. I installed into /my/prefix and found my libs in /my/prefix/usr/local/lib. INSTALL_PREFIX must be changed in config/defaults or something like that. The mesa devs are scoring very low on the build engineering front.

  3. Robert,

    DESTDIR wasn’t there before; at least it wasn’t in 7.0.1. I just checked (with “grep -r DESTDIR *”). INSTALL_DIR (it’s not INSTALL_PREFIX) was always there, perhaps that’s what you meant.

    Perhaps you’re misunderstanding the purpose of DESTDIR – it provides a way to install to an “alternative root” and is mostly useful for binary package maintainers (it allows things like “make DESTDIR=/tmpdir install; cd /tmpdir; tar -czf binarypkg.tar.gz”). It was sorely lacking in Mesa before version 7.0.2, though it was possibly in a very clunky way to achieve the same effect by modifying INSTALL_DIR.

    To sum up:
    INSTALL_DIR is the (root of the) final location where the location will be installed, when it is active in a system.
    DESTDIR is an alternative root for installation, to be used mainly when you don’t want to actually install the package into your system, but instead want to bundle it up as a binary package.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s