MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012357CMakeCMakepublic2011-07-23 16:042012-03-06 08:37
ReporterMichael Lowell Roberts 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformVisual Studio 10OSWindowsOS VersionXP
Product VersionCMake 2.8.5 
Target VersionFixed in VersionCMake 2.8.6 
Summary0012357: ExternalProject.cmake ignores prefix when installing a CMake project.
DescriptionIf used on a CMake project, ExternalProject.cmake installs the external project into ${CMAKE_INSTALL_PREFIX}, not the default location specified by ExternalProject.cmake, nor any paths specified with the PREFIX or INSTALL_DIR keywords.
Steps To ReproduceI've attached a copy of my project that can be used to reproduce the issue. This only reproduces the problem on Windows. In Linux, ExternalProject invokes automake to compile the external project (trio) instead of CMake.

1. Unpack the attached archive onto a Windows system.
2. Configure the project. I use Visual Studio 10 Express.
3. CMake will inform you that trio could not be found. Set the TRIO_DOWNLOAD cache variable to YES and reconfigure to address this.
4. Perform the generate step.
5. Build the project. You'll encounter the following messages:
  
    -- Install configuration: "Debug"
  
    -- Up-to-date: C:/Program Files/trio/include/trio.h
  
    -- Up-to-date: C:/Program Files/trio/include/triop.h
  
    -- Up-to-date: C:/Program Files/trio/include/triodef.h
  
    -- Up-to-date: C:/Program Files/trio/include/trionan.h
  
    -- Up-to-date: C:/Program Files/trio/include/triostr.h
  
    -- Installing: C:/Program Files/trio/lib/trio.lib

...

C:\Documents and Settings\...\fmrl-ramalloc-991e072\src\test\shared\test.c(39): fatal error C1083: Cannot open include file: 'trio.h': No such file or directory

This is because trio has been installed into "C:/Program Files/trio" instead of ${CMAKE_CURRENT_BINARY_DIR}/trio-prefix, where it is expected to be installed.

Additional InformationThe script that calls ExternalProject_Add() can be found in "cmake/trio.cmake".

I've included a patch to ExternalProject.cmake in the source archive that appears to fix the problem. This patch is located at "cmake/trio/cmake-fix-external-install.diff".

Due to the difference in how I use ExternalProject.cmake on different platforms, however, I'm unable to confirm that patch this fixes the issue on non-Windows platforms.
TagsNo tags attached.
Relationships
Attached Fileszip fmrl-ramalloc-release-0-105-g991e072.zip (232,632) 2011-07-23 16:04
https://public.kitware.com/Bug/file/3980/fmrl-ramalloc-release-0-105-g991e072.zip
Issue History
Date ModifiedUsernameFieldChange
2011-07-23 16:04Michael Lowell RobertsNew Issue
2011-07-23 16:04Michael Lowell RobertsFile Added: fmrl-ramalloc-release-0-105-g991e072.zip
2011-07-27 12:29David ColeAssigned To => David Cole
2011-07-27 12:29David ColeStatusnew => assigned
2011-10-03 10:02David ColeNote Added: 0027509
2011-10-04 21:42Michael Lowell RobertsNote Added: 0027524
2011-10-05 15:19David ColeNote Added: 0027527
2011-10-05 15:19David ColeStatusassigned => resolved
2011-10-05 15:19David ColeFixed in Version => CMake 2.8.6
2011-10-05 15:19David ColeResolutionopen => no change required
2012-03-06 08:37David ColeNote Added: 0028820
2012-03-06 08:37David ColeStatusresolved => closed

Notes
(0027509)
David Cole   
2011-10-03 10:02   
If you would like a CMAKE_INSTALL_PREFIX different than the default for a given call to ExternalProject_Add, then you should say so in your arguments to ExternalProject_Add. For example,

ExternalProject_Add(trio
  ...
  CMAKE_ARGS
    -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
  ...
  )

I don't think the "cmake/trio/cmake-fix-external-install.diff" patch is a good idea because then it forces *all* calls to ExternalProject_Add to use such a value for CMAKE_INSTALL_PREFIX. Some existing callers, I'm quite sure, are already providing custom overrides for this value on a per-project basis.

I'll resolve this as "no change required" unless you have a very good counter-argument for why we should consider using such a patch in the general case.
(0027524)
Michael Lowell Roberts   
2011-10-04 21:42   
Hi David,

I appreciate your effort to investigate this for me.

I tried your suggestion and it works just fine with an unmodified CMake. I will therefore stay with that solution.

I'll trust your wisdom regarding acceptance of the patch I submitted.

Thanks,
Mike
(0027527)
David Cole   
2011-10-05 15:19   
Resolving as "no change required" as discussed in previous notes...
(0028820)
David Cole   
2012-03-06 08:37   
Closing resolved issues that have not been updated in more than 4 months.