[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q: 'make prefix=/new/path install'

From: Daniel Herring
Subject: Re: Q: 'make prefix=/new/path install'
Date: Tue, 4 Nov 2008 22:19:49 -0500 (EST)
User-agent: Alpine 1.10 (LNX 962 2008-03-14)

On Tue, 4 Nov 2008, Ralf Wildenhues wrote:
* Daniel Herring wrote on Tue, Nov 04, 2008 at 07:13:23AM CET:
I would like to build and install several revisions of a large system
(hours to compile on slower machines).

My hope was to build the project in a central location so unchanged files
wouldn't need to recompile, and then have libtool relink everything and
fix the RPATHs during install.  This doesn't seem to be happening.

I'm not quite sure I completely understand what you are trying to do, so
let me explain what I *think* you are doing.

With autotools, conceptually there are three different directory trees:
- the source tree (contains 'configure' script in toplevel),
- the build tree (is current working directory when configure is run;
 also, contains 'config.status' script in toplevel),
- the install tree (set with the configure argument '--prefix').

IIUC then you would like to have one (presumably the oldest) revision of
some source tree set up, then you build, then install somewhere.  Then,
change the source tree to contain a different revision, reuse the build
tree without removing the object files, but diverting to a different
installation location using 'make install prefix=...'.

Is that correct?

That's a good description.

If yes, then the answer is: Libtool doesn't support that late prefix
diversion, unfortunately.  I'm not sure whether that can be fixed, but
it wouldn't be easy, due to the obscurities of some system's shared
library semantics.  And yes, this is a violation of the GNU Coding
Standards (GCS).  (If pressed, I'd probably go for changing the GCS

FWIW, it seems that libtool is already relinking executables against shared libraries during `make install`; it just isn't updating the RPATH or .la files. But the obscure library semantics don't sound fun.

Here's a slightly different way out: usually, it should suffice to rerun
configure from that same build tree again, with changed --prefix.  Then
run 'make' without cleaning first.  This works with many packages (but
can sometimes fail, due to package-specific rules issues).

It even sometimes works to keep a config.cache file (configure -C)
between the runs, if the revisions haven't changed configure test
semantics a lot, and if the cache variables are used carefully to
not depend upon the values of --prefix and --bindir and the other
directory variables.

When the config.cache is used, then this alternative method should
only be marginally slower than what you originally tried.  Even without,
it should not be too much.

Good idea. If it were just me, I'd go for it; our configure script and makefiles don't do anything funny with the prefix. As it is, I've had enough fun getting this project upgraded to autotools (from buggy makefiles), and I don't think people would like or remember to run configure before every upgrade/install.

Static libs work for now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]