[MINC-development] AX_CHECK_GL and friends

[Steve M. Robbins]

On Fri, Apr 01, 2005 at 10:27:46PM +1000, Andrew Janke wrote:

> Whilst on the subject of libtool, do you happen to know of any way
> whereby you can force libtool to use relative paths (or facillitate
> prefixed installs?)
> 
> Reason being is that when building binary packages, Ibuild in a
> quarrantined directory so that I can check dependencies.  ie:
> 
>     ./configure --prefix=/tmp/epm-build/target/minc-${vers}  \
>          --with-build-path=/tmp/epm-build/target/comb
> 
> Then I build the binry package from the prefix before synching the
> result to the comb directory for building against (could use stow
> here, but haven't got to it). Problem is, the .la file paths are now
> all way of course.

Where is the package going to be installed?  Let's say it should
ultimately appear in /minc-${vers}/{bin,lib,etc}.  Then you must
configure and build using --prefix=/minc-${vers}, ditto for
--with-build-path.  I don't know of any way around this short of
sneaky, brittle sed-tricks on the .la file.

It sounds like you are building up the quarantine one package at
a time (MINC, BICPL, Display, ...) but you want to make a binary
of each package separately?

The solution is easy for packages that use automake: they always
support DESTDIR.  What you do is configure with the desired prefix,
/minc-${vers}, but install into a staging directory, say
/tmp/staging/minc-${vers}.

    ./configure --prefix=/minc-${vers} --with-build-path=/minc-${vers}
    make all test
    make install DESTDIR=/tmp/staging

The configuration and make will build .la files that refer to
/minc-${vers}, but the "make install" line will install into
directories rooted at $DESTDIR/$prefix; i.e. into
/tmp/staging/minc-${vers}/{bin,lib,etc}.  Then you simply build
the binary package from $DESTDIR.  This is a standard trick for
Debian packaging (presumably others', too).

For your quarantine you'd also want to do a regular "make install" so
that it appears in /minc-${vers}, available for the next package on
the list.  Or install the newly-created package.


> I guss the other thing I could do is chroot for
> the binary build, but chroot/fakeroot doesn't exist on all platforms.

Worse: you probably don't have a compiler and other build tools
in /tmp/epm-build/target/comb, so a chroot build will fail for
this reason.

-Steve