Nick Bowler wrote: > Substituting > directory variables at configure time is basically impossible to do in a > manner that is compliant with the GNU coding standards, because the > standards say that the user can specify prefix on the make command line > instead of (or in addition to) the configure command line. > > % ./configure --prefix=/some/where > % make prefix=/some/where/else > > to work and I imagine it does not work in your example.
You are apparently referring to (1) https://www.gnu.org/prep/standards/standards.html#Configuration which lists the configure options, (2) https://www.gnu.org/prep/standards/standards.html#Directory-Variables which says "Installers are expected to override these values when calling make (e.g., make prefix=/usr install) or configure (e.g., configure --prefix=/usr)." But there is also (3) https://www.gnu.org/prep/standards/standards.html#Standard-Targets ‘install’ If possible, write the install target rule so that it does not modify anything in the directory where the program was built, provided ‘make all’ has just been done. So, the ability to run make prefix=/usr install is limited to packages where programs don't need to reference installed data files. Because when a program needs to reference installed data, most packages do so by hardcoding the relevant installation directory somewhere in the executable. This is because the alternatives are often not viable: - Only very few packages provide a "relocatable" installation, where the programs will look up the installation directories dynamically. - 'make install' is meant to copy built programs from 'make all', and replacing hardcoded strings in an executable on-the-fly is not portable. So, for such packages, it is *normal* that the binaries contain the values of PREFIX, LOCALEDIR, etc. — and passing a different prefix at 'make install' time cannot change that. Bruno
