Re: CC=cc ./configure or ./configure CC=cc

[Ralf Wildenhues]

* Ed Hartnett wrote on Tue, Aug 08, 2006 at 04:56:31PM CEST:
> Bruno Haible <address@hidden> writes:
> 
> > 4) If "./configure CC=cc" is supported, people may easily think the
> >    same holds for "make". Such as "make CC=cc" or
> >    "make install prefix=/opt/gnu". But these are unsupported (the
> >    first one because so many details about $CC are extracted into
> >    config.h, the second one because paths to message catalogs etc.
> >    are hardcoded into the built executables).

> Is the "make install prefix=/something" method OK for static libraries
> and executables? 

In practice, you cannot expect a package to be relocatable.  Usually,
  make install DESTDIR=/tmp/stage

works, in the sense that if the files are later moved to the $prefix
that was originally configured, then things will work as intended.
(Automake's "make distcheck" tests that the above works.)

If you have taken measures to make your package relocatable, then it may
work to
  make install prefix=/something

and expect to use file appearing below /something later; typically, when
using Libtool this will fail if you use shared libraries and any of the
installed locations are nonstandard (i.e., not searched for by default
by the runtime loader).

> Also is it just a GNU make thing, or is it widely supported in makes?

Overriding make macros on the command line is widely supported in makes.
HOWEVER:  for some non-GNU makes, those overrides don't make it into a
sub-make invocation.  (Automake-generated Makefiles may even contain
sub-make invocations inside the current directory!)

You can get around that portably by using
  env VAR=setting make -e

but this may get you a bunch of other problems, depending on your
environment (e.g., you have CC set in your environment).

> I get questions of how to change the install directory after the
> package is already built. 

The safe answer is: don't.  Do a re-configure.
Remind users to use a separate build tree for every installation,
in case they want to keep around the build trees for longer.

> Usually someone forgets to specify the --prefix option to configure,
> and remembers after the package is all built that they want it
> someone other than the default location. Is their only recourse to
> rerun configure?

It's the safest.

> (And in the case of shared libraries, they must run make clean first
> too, right?)

Yes.

Cheers,
Ralf