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

[Ralf Wildenhues]

Hello Daniel,

* 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?

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
instead.)

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.

Hope that helps.

Cheers,
Ralf