[cmake-developers] DESTDIR does not work correctly with install(FILES ... signature

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon Jan 7 20:58:59 EST 2013


Here is a simple project to show the issue summarized in the subject
line for the default "Unix Makefiles" generator on Linux.

# Test DESTDIR
cmake_minimum_required (VERSION 2.8.5)
project (test_destdir NONE)

INSTALL(CODE "
  FILE(MAKE_DIRECTORY $ENV{DESTDIR}/whatever)
  ")

This does not work correctly with either 2.8.5 or 2.8.10.2.
The above idea of using $ENV{DESTDIR} for this case was taken
from an old Brad King post to the cmake mailing list so
in case that post was outdated, I also tried dropping $ENV{DESTDIR}
from the above test project, but that failed in the same way
as described below.

cmake does not generate any error messages for all cases I
tried.  However, in all cases the issue is $ENV{DESTDIR} is completely missing as a prefix to
/whatever in cmake_install.cmake, i.e.,

software at raven> grep -n whatever cmake_install.cmake 
37: FILE(MAKE_DIRECTORY /whatever)

Because of that issue you get the following error from "make" for that
same line in the file.

software at raven> make DESTDIR=/tmp/test_DIR install
Install the project...
-- Install configuration: "Release"
CMake Error at cmake_install.cmake:37 (FILE):
   file problem creating directory: /whatever

If I hand-edit that file to fix up the issue, all is well

software at raven> grep -n whatever cmake_install.cmake 
37: FILE(MAKE_DIRECTORY $ENV{DESTDIR}/whatever)
software at raven> make DESTDIR=/tmp/test_DIR install
Install the project...
-- Install configuration: "Release"
software at raven> ls /tmp/test_DIR/
whatever/

Since the fundamentals of the above test project were copied from an
old cmake mailing list post from Brad King, this issue for 2.8.5 and
2.8.10.2 may be a regression against some previous version of cmake.

I am trying to get releases for two separate projects out the door
so any quick workaround suggestions for the DESTDIR issue would be welcome.

My exact use case for those two projects (as well as PLplot) doesn't
use FILE, but that was the easiest way to demonstrate the issue above.
Instead, I am copying doxygen-generated documentation from the build
tree to the install tree at install time for all three projects using

  install(CODE "
  message(STATUS \"Installing: $ENV{DESTDIR}${DOC_DIR}/doxygen tree\")
  execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/doxygen $ENV{DESTDIR}${DOC_DIR}/doxygen)
")

cmake (incorrectly) drops $ENV{DESTDIR} when translating
these instructions to doc/cmake_install.cmake, i.e.,

software at raven> grep -n doxygen doc/cmake_install.cmake 
53:message(STATUS "Installing:
/home/software/plplot_svn/installcmake/share/doc/plplot/doxygen tree")
54:execute_process(COMMAND
/home/software/cmake/install-2.8.10.2/bin/cmake -E copy_directory
/home/software/plplot_svn/HEAD/build_dir/doc/doxygen
/home/software/plplot_svn/installcmake/share/doc/plplot/doxygen)

(This example is for PLplot, but the actual two urgent releases
that use similar logic are ephcom and te_gen.)

So if there is no quick way to fix this DESTDIR issue, then can
somebody suggest a different alternative that can quickly be
implemented for installing doxygen-generated files in the install-tree
that is sensitive to DESTDIR?  I don't think there are any guarantees
that doxygen-generated files have the same names from one doxygen
release to the next so any solutions should not use the assumption of
fixed names for that relatively large number of different files.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



More information about the cmake-developers mailing list