Escape the $ in the original, so it's still there in the generated install
script.
i.e., \$ENV{DESTDIR} should yield $ENV{DESTDIR} in the install script.
CMake is *correctly* replacing the ENV reference with its current value at
CMake configure time. But you want it to happen at install time.
HTH,
D
On Monday, January 7, 2013, Alan W. Irwin wrote:
> 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@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@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@raven> grep -n whatever cmake_install.cmake 37:
> FILE(MAKE_DIRECTORY $ENV{DESTDIR}/whatever)
> software@raven> make DESTDIR=/tmp/test_DIR install
> Install the project...
> -- Install configuration: "Release"
> software@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@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
> __________________________
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ<http://www.cmake.org/Wiki/CMake_FAQ>
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developers<http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers>
>
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
