Project

General

Profile

Bug #555

DESTDIR no longer recognized for 'make install-mdrun' when using cmake

Added by Nicholas Breen about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

As of this writing, release-4.5-patches does not take into account $DESTDIR on a "make install-mdrun", trying to install directly to CMAKE_INSTALL_PREFIX instead. It does work as expected for a full "make install".

Steps:

mkdir build install
(cd build ; cmake .. -DCMAKE_INSTALL_PREFIX="/usr")
make -C build mdrun
make -C build install-mdrun DESTDIR=`pwd`/install

The tail end of that last command's output:

Scanning dependencies of target install-mdrun
make3: Leaving directory `/tmp/gromacs-4.5.1+git20100909/build'
make3: Entering directory `/tmp/gromacs-4.5.1+git20100909/build'
[100%] Installing mdrun
Error copying file "/tmp/gromacs-4.5.1+git20100909/build/src/kernel/mdrun" to "/usr/bin/mdrun".
make3: * [src/kernel/CMakeFiles/install-mdrun] Error 1
make3: Leaving directory `/tmp/gromacs-4.5.1+git20100909/build'
make2:
[src/kernel/CMakeFiles/install-mdrun.dir/all] Error 2
make2: Leaving directory `/tmp/gromacs-4.5.1+git20100909/build'
make1:
[src/kernel/CMakeFiles/install-mdrun.dir/rule] Error 2
make1: Leaving directory `/tmp/gromacs-4.5.1+git20100909/build'
make: *
[install-mdrun] Error 2
make: Leaving directory `/tmp/gromacs-4.5.1+git20100909/build'

Associated revisions

Revision 36133dbe (diff)
Added by Teemu Murtola about 9 years ago

Use CMake install for install-mdrun (bugs #549, #555)

The custom target install-mdrun now invokes the cmake_install.cmake
script that is generated by CMake to perform the actual installation.
Adds support for DESTDIR and RPATH rewriting (see bug #570).

To implement this, all installation targets are now grouped into
components: "data" for shared data, "development" for headers and
pkgconfig files, "libraries" for libraries needed by mdrun, "mdrun" for
mdrun itself, and "runtime" for other binaries and libraries. Only
"mdrun" and "libraries" are used at the moment (the latter only when
installing with shared libraries).

Haven't tested this with Visual Studio, but if it doesn't work, it
should be easy to adapt.

History

#1 Updated by Szilárd Páll about 9 years ago

(In reply to comment #0)

As of this writing, release-4.5-patches does not take into account $DESTDIR on
a "make install-mdrun", trying to install directly to CMAKE_INSTALL_PREFIX
instead. It does work as expected for a full "make install".

My bad, I forgot about taking into account DESTDIR. As the install-mdrun is a custom target which means that it just simply copies the binary to ${CMAKE_INSTALL_PREFIX}/bin, everything has to be coded by hand.

I will look into the problem and will try to fix it. However, I'm not sure how easy it is to make it work in all 4 forms it works with autoconf:
(1) make install DESTDIR="/some/absolute/path"
(2) make DESTDIR="/some/absolute/path" install
(3) DESTDIR="/some/absolute/path" make install
(4) export DESTDIR="/some/absolute/path
make install

While (3) and (4) shouldn't be a problem, (1) and (2) might be problematic. Do we want all 4 forms?

#2 Updated by Erik Lindahl about 9 years ago

Szilard is the expert here, but at some point we might have to let go of autoconf-centric features and accept that cmake does things a bit different!

#3 Updated by Nicholas Breen about 9 years ago

Any of 1-3 should serve well as long as the build documentation is brought into line. I don't think the implementation needs to match autoconf all the way down the line, but the general feature remains useful in the very common case that gromacs is built on one machine for later installation on another.

#4 Updated by Szilárd Páll about 9 years ago

(In reply to comment #3)

Any of 1-3 should serve well as long as the build documentation is brought into
line. I don't think the implementation needs to match autoconf all the way
down the line, but the general feature remains useful in the very common case
that gromacs is built on one machine for later installation on another.

While trying to implement this feature I realized that it's either impossible or overly complicated to do it such that cmake does not need to be rerun after the DESTDIR env var is set, which defeats the purpose of the mechanism. Therefore I am marking this bug "won't fix" and will add a remark to the wiki!

#5 Updated by Erik Lindahl about 9 years ago

Hi,

I'm not sure what the use for $DESTDIR is when applied to a single-binary install?

It is critical to understand that $DESTDIR is not a substitute for CMAKE_INSTALL_PREFIX; the final install location when a binary is used should always be CMAKE_INSTALL_PREFIX, since that is used e.g. for internal paths to data directories.

In contrast, $DESTDIR is used for a temporary location where the binaries might not even be functional, for instance when building RPM/DEB packages without root permission. Do we ever do that just for mdrun?

#6 Updated by Nicholas Breen about 9 years ago

(In reply to comment #5)

In contrast, $DESTDIR is used for a temporary location where the binaries might
not even be functional, for instance when building RPM/DEB packages without
root permission. Do we ever do that just for mdrun?

That's exactly what I'm doing, in fact. Debian/Ubuntu ships a separate mdrun-only package for each MPI implementation in the distribution.

#7 Updated by Jussi Lehtola about 9 years ago

Ugh, I ran into this as well as I started working on upgrading the Fedora & RHEL packages of Gromacs to 4.5.1. Could this please be fixed? :)

#8 Updated by Erik Lindahl about 9 years ago

Hi Jussi,

The safe solution for now is to stick to autoconf if you absolutely need this functionality - I assume Cmake doesn't play very nice with source RPM/DEBs anyway?

Our problem is that it isn't merely a bug in our files - Cmake simply doesn't support arbitrary sub-target-installation with DESTDIR for now, and we'd rather not end up re-implementing autoconf inside cmake.

#9 Updated by Teemu Murtola about 9 years ago

(In reply to comment #8)

Our problem is that it isn't merely a bug in our files - Cmake simply doesn't
support arbitrary sub-target-installation with DESTDIR for now, and we'd rather
not end up re-implementing autoconf inside cmake.

As I've commented in several different contexts now, I think that if we were to use the same mechanism as used internally by CMake for install-mdrun, all of this would simply work. CMake does seem to support grouping installation targets into "components", and I think (but haven't tried, and I'm not aware that anyone else would have either) that it would be possible to implement the install-mdrun target as simply installation of one or two of these components. If we are really lucky, CMake might even create those custom installation rules automatically. If it doesn't, there may not be a direct CMake command for doing this, but using cmake -P cmake_install.cmake with appropriate -D flags as a command for a custom target would most likely work.

#10 Updated by Teemu Murtola about 9 years ago

There's a preliminary patch that fixes this issue as well attached to bug #549.

#11 Updated by Szilárd Páll about 9 years ago

As Teemu's fix bring DESTDIR support back I'm reopening this bug (until the patch gets applied).

#12 Updated by Teemu Murtola about 9 years ago

Fixed in commit 36133dbe2037f86b2791771259cbed6058886948 (see also bug #549).

Also available in: Atom PDF