make install prefix=foo fails

[ohl]

e.g.:

make -C _build_gfortran install prefix=/home/ohl/physics/whizard/_inst_hsr1

looses on

 /bin/sh ../libtool   --mode=install /usr/bin/install -c  'libomega.la' '/home/ohl/physics/whizard/_inst_hsr1/lib/whizard/libomega.la'
libtool: install: error: cannot install `libomega.la' to a directory not ending in /home/ohl/physics/whizard/_inst_gfortran/lib/whizard
make[3]: *** [install-pkglibLTLIBRARIES] Error 1

This should work per automake philosophy.

[Juergen Reuter]

I don't understand this, it works for me.

[Juergen Reuter]

Result of Freiburg discussions: As paths are hard-coded this cannot work. Won't fix.

[ohl]

Guys, not so fast: according to ​http://www.gnu.org/software/automake/manual/autoconf.html#Installation-Directory-Variables

Most of these variables have values that rely on prefix or exec_prefix. It is deliberate that the directory output variables keep them unexpanded: typically '@datarootdir@' is replaced by '${prefix}/share', not '/usr/local/share', and '@datadir@' is replaced by '${datarootdir}'. This behavior is mandated by the GNU Coding Standards

In fact, this behavious is very useful. E.g. for checkpointing a compiled version in order to run regression tests on develepment version, this feature saves complete recompilations.

This is not trivial (see also ​http://www.gnu.org/software/automake/manual/automake.html#Hard_002dCoded-Install-Paths), but we should try eventually. I'm reopening this with the lowest priority.

[Juergen Reuter]

Maybe this has already been solved by relying on standard paths now in WHIZARD? TO, could you please check?

[ohl]

Replying to jr_reuter:

Maybe this has already been solved by relying on standard paths now in WHIZARD? TO, could you please check?

Nope. This still fails.

[Juergen Reuter]

This can be shifted, it is not sooo important.

[Juergen Reuter]

I started to have a look into this. It started to work for the CIRCE1/2 packages correctly but then stumbled over the installation of the cache files. These are reset to $localstatedir/cache in order to offer the user the possibility to specify this directory separately, but should be set to $prefix/var/cache if the flag is not set by the user. Reason is, that WHIZARD tries to install /usr/local/var/cache otherwise to which a user does not have write permissions.

[Juergen Reuter]

So, there are several issues: this problem is more or less well-known and appears in other applications, too: ​https://wwws.clamav.net/bugzilla/show_bug.cgi?id=746. It was speculated that this might even be a libtool problem: ​http://lists.gnu.org/archive/html/libtool/2006-09/msg00066.html. I fear that the remark above about the hard-coded paths is finally correct, and there is no way out of this problem.

[Juergen Reuter]

The workaround proposed in ​https://wwws.clamav.net/bugzilla/show_bug.cgi?id=746 partially works. make prefix=foo and afterwards make install prefix=foo both run through. But the libraries are not found and the installed version cannot be run. make installcheck has at least to be replaced by make installcheck prefix=foo but the shell scripts for the test do not run because there the path for the WHIZARD binary is determined from the configure run. Also, the SM model file is not found for the very same reason. Trying to find a way out of this path dependencies, but might be difficult.

[Juergen Reuter]

More and more I have the feeling that such an autotools feature is incompatible with the hard-coded paths such we have them in system_dependencies.f90.in and run_whizard.sh.in. Probably we just have to demand that ./configure --prefix=foo is used and that's it.

[Christian Speckner]

As far as I know, the feature does not necessarily intent that the program runs from the new location, but only that the files get copied there. An obvious use for this is the creation of a tarball which can then be deployed untarred to the proper location. In fact, I was unaware that this doesn't work --- I am pretty sure I used this feature in order to deploy WHIZARD on the FeynRules? model testing cluster... What won't work for sure is straightforward running of the program from the staging directory - we have too many hardcoded paths for this, but command line options to WHIZARD can be used to bend the paths to the proper locations (I checked this for the instant-WHIZARD bundle).

[Juergen Reuter]

Yes, fine, but what is the conclusion from this?

[Juergen Reuter]

Can we roll up this one right now, as we fixed all the stuff with the paths? Now that we still know what we did for the other tickets in that respect...

[Juergen Reuter]

After discussion with CS, there is not much left to do here. Again, no further reaction on that one.... Same here, no reaction until wednesday before Easter => close as invalid.

[Juergen Reuter]

Again discussing the topic with CS yesterday, and since nobody complained about it, I'm closing this ticket now.