Re: [gnu.org #742057] Make standard targets

[Alfred M. Szmidt]

   > It is simple enough to recompile a program, and there is little
   > benefit in looking things up at run-time.

   Position independence is generally a good idea. Position dependence
   is brittle.

   Here’s an example: I have two versions of apache, the installed
   version, and the new version for testing. Once the new version is
   blessed, I move the installed version from the main installed
   location to /usr/local/apache-previous or suchlike, and move the
   staging version into the main installed location. I can still test
   on the old version for sanity checks by using it in its new
   location. Having to use make install again twice to make this work
   is waste and invites errors.

You can achive this better by doing,

./configure --prefix=/usr/local/program-0.01 && make install
./configure --prefix=/usr/local/program-0.02 && make install

where 0.01 is your stable version, and 0.02 is the one you are
testing.  When you are done testing, you can update your start
scripts, or PATH to use the correct version.

I use something like this,

./configure --prefix=~/local/gcc-4.7.0 
--exec-prefix=~/local/gcc-4.7.0-$(./config.guess)
make install

so I can have the same version for multiple operating system, and save
some bytes for shared data, and have the same configuration file
(since it will look for it in ~/local/program/etc since --sysconfdir
is ${prefix}/etc by default) across all machines I work on.  Immensly
useful!

   >> Thinking about this some more, being able to change the prefix
   >> with minimal rebuilding is a feature that goes along with my
   >> proposal.
   > 
   > `make install' doesn't rebuild anything in a already built
   > directory; even if you set prefix during `make install' it will
   > not rebuild (if it does, it is a bug in the package).

   I don’t recall ever reading in configure documentation that prefix=
   works as an argument to make install

>From (standards.info) Directory Variables: "Installers are expected to
override these values when calling `make' (e.g., `make prefix=/usr
install' or `configure' (e.g., `configure --prefix=/usr')."

   So I tried an experiment
     Z% ./configure prefix=/usr/local/gcc-4.7.0
     Z% make
     Z% make install
     Z% make prefix=/home/yost/gcc-4.7.0 install
     Z% find /home/yost/gcc-4.7.0 -type f | exec tr '\012' '\000' | xargs -0 
"$@" strings | grep /usr/local/gcc-4.7.0 | wc
       139     259    7642
     Z% find gcc-4.7.0 -type f | exec tr '\012' '\000' | xargs -0 "$@" strings 
| grep /home/yost | wc 
         0       0       0

I am not sure what you are trying to explain here; but I misunderstood
you the first time.  `make install prefix=...' does not recompile the
program, so whatever was used in the program will be what it was when
it was compiled/configured.

You wish to rebuild the program (quickly) with a different prefix in
the compiled executables.  `./configure -C' and ccache go along way in
speeding up compiles in most cases.  There is no other way of doing
that currently, nor would it be possible to do in an easy fashion.

   >> 1. I installed temporarily into /usr/local/gcc-4.7.0/ until we
   >>    decide that we are ready to cut over. Then I will install
   >>    into /usr/local/. It would be nice to be able to edit a file,
   >>    say “config-prefix”, then do a make install, and not have to
   >>    wait hours.
   > 
   > `make install' is fairly quick; if it takes hours then you are
   > doing something terribly wrong.

   What does take quite a bit of time is running configure again with
   a different prefix. It was my understanding that you had to do this
   to change prefix.

If you are recompiling/reconfiguring you can use the -C flag to build
a cache to speed up ./configure.

   > Second, it would be impossible to find system configuration
   > files, libexec type programs, etc without a lot of complicated
   > FOO_PATH and FOO_PROGRAM variables.

   I don’t understand point two. Can you give an example?

In the normal case, inetd reads SYSCONFDIR/inetd.conf (where
SYSCONFDIR is PREFIX/etc by default).  If now inetd is changed to
automatically find inetd.conf, where does it find it if I put my inetd
executable in ~/, /usr/libexec and /usr/local/libexec and execute eash
one of those?

Would inetd search the current working directory for it (lots of
security problems there)?  Would it search the directory where the
executable is is for inetd.conf (security again, won't typically exist
if you are hacking)?  Maybe the variants of the previous but ../etc
(~/../etc/inetd.conf would be weird)?

What if my copy in ~/ uses a newer configuration file format?


And what about for example, emacs that uses the libexec program
(executables that are not supposed to be run by a user directly, and
thus not found in PATH) movemail.  How would emacs find this in a
dynamic manner?  Currently it looks at a variable called exec-path
that contains, amongst other, LIBEXECDIR/ which is set during
configure/compile time.

Keep it simple, and don't suprise the user.  The current way is
flexible, simple, and doesn't suprise you.  What you suggest wouldn't
provide much benefit over the existing method.