MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011950CMakeCMakepublic2011-03-09 11:242011-03-09 14:21
ReporterBen Hines 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformlinuxOSubuntuOS Version10.10
Product VersionCMake 2.8.4 
Target VersionFixed in VersionCMake 2.8.3 
Summary0011950: install.cmake file assumes RELEASE install
DescriptionHi,

Used CMake to generate make files for a static library on linux. In my CMakeLists.txt file, I added a line for setting debug postfix as "d". I have generated makefiles with CMake for both the debug and release configs. They "make" correctly, resulting in mylib.lib and mylibd.lib for release and debug. However, when I go to the debug build area and type "make install" it always attempts to install the "release" version. In fact, if I haven't yet built the release configuration, then "make install" (from the debug config) fails because it can't find mylib.lib.

I noticed in the generated install.cmake file, that there is a condition on the CMAKE_INSTALL_CONFIG_NAME variable. If I explicitly set this to "Debug" in the install.cmake file, it works correctly and copies "mylibd.lib" to the install directory. This, unfortunately, isn't a solution because my edits to install.cmake are wiped out the next time I generate the file.

When running cmake to generate the debug build, I tried using the "-D" option to define the CMAKE_INSTALL_CONFIG_NAME to be debug as follows:

-DCMAKE_INSTALL_CONFIG_NAME:STRING=Debug

I verified in the resultant CMakeCache.txt that the variable is set and it is. However, when I run "make install" it still tries to install the release library.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0010202closed Brad King CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE weird behaviour 
Attached Filesgz exampleproject.tar.gz (19,856) 2011-03-09 13:35
https://public.kitware.com/Bug/file/3746/exampleproject.tar.gz
Issue History
Date ModifiedUsernameFieldChange
2011-03-09 11:24Ben HinesNew Issue
2011-03-09 11:43Brad KingNote Added: 0025711
2011-03-09 12:09Ben HinesNote Added: 0025712
2011-03-09 12:43Brad KingNote Added: 0025713
2011-03-09 12:49Ben HinesNote Added: 0025715
2011-03-09 12:52Ben HinesNote Added: 0025716
2011-03-09 13:02Brad KingNote Added: 0025717
2011-03-09 13:22Ben HinesNote Added: 0025719
2011-03-09 13:26Brad KingNote Added: 0025720
2011-03-09 13:27Ben HinesNote Added: 0025721
2011-03-09 13:35Ben HinesFile Added: exampleproject.tar.gz
2011-03-09 13:37Ben HinesNote Added: 0025722
2011-03-09 14:19Brad KingAssigned To => Brad King
2011-03-09 14:19Brad KingStatusnew => assigned
2011-03-09 14:19Brad KingRelationship addedduplicate of 0010202
2011-03-09 14:21Brad KingNote Added: 0025723
2011-03-09 14:21Brad KingStatusassigned => closed
2011-03-09 14:21Brad KingResolutionopen => duplicate
2011-03-09 14:21Brad KingFixed in Version => CMake 2.8.3

Notes
(0025711)
Brad King   
2011-03-09 11:43   
What CMake command did you run to create each of the two build trees (e.g. Debug and Release)? Did you set CMAKE_BUILD_TYPE in either one?
(0025712)
Ben Hines   
2011-03-09 12:09   
For the debug config, the command looks like this:
cmake -G "Unix Makefiles" -DLINUX:BOOL=True -DCMAKE_INSTALL_CONFIG_NAME:STRING=Debug -DCMAKE_BUILD_TYPE=Debug ../../../

And for release:
cmake -G "Unix Makefiles" -D LINUX:BOOL=True -DCMAKE_INSTALL_CONFIG_NAME:STRING=Release -DCMAKE_BUILD_TYPE=Release ../../../
(0025713)
Brad King   
2011-03-09 12:43   
The CMAKE_INSTALL_CONFIG_NAME variable is local to the cmake_install.cmake scripts only. The cache is not loaded when those scripts are run so it makes no difference to set it when running CMake to generate the build tree. However, the default generated in cmake_install.cmake should be the value of CMAKE_BUILD_TYPE. After each of the commands you mentioned in 0011950:0025712 the cmake_install.cmake default should match the build type. Is that not the behavior you see?
(0025715)
Ben Hines   
2011-03-09 12:49   
Regarding the CMAKE_INSTALL_CONFIG_NAME variable... Yep I noticed that it was being ignored by the install.cmake file, but forgot to remove it from the command line.

Here is the output I see when I build the generate, make and make install the debug configuration:
---------------------------------------------
[100%] Built target zlib
Install the project...
-- Install configuration: "Release"
CMake Error at src/cmake_install.cmake:40 (FILE):
  file INSTALL cannot find
  "/home/ben/Desktop/thor/thirdparty/zlib/bin/linux/libz.a".
Call Stack (most recent call first):
  cmake_install.cmake:37 (INCLUDE)


make: *** [install] Error 1
---------------------------------------------

Notice the Configuration: "Release" line. It fails because it's looking for the release library, which hasn't been built yet.
(0025716)
Ben Hines   
2011-03-09 12:52   
I forgot to mention...

I noticed that the cmake_install.cmake file references a varialbe called "BUILD_TYPE". In your previous note you mention (and on my command line I set) "CMAKE_BUILD_TYPE". Could this be the problem? Should the generated cmake_install.cmake file be refernencing "CMAKE_BUILD_TYPE"?
(0025717)
Brad King   
2011-03-09 13:02   
Re 0011950:0025716: No, the BUILD_TYPE variable is there so one can do

  cmake -DBUILD_TYPE=Debug -P cmake_install.cmake

to install with a specific configuration. It is used by VS IDE and Xcode generators which actually have multiple configurations in a single build tree and need to know at install time which configuration to install. This is an internal implementation detail and not part of the documented interface.

Re 0011950:0025715: I can't reproduce that. If I run with -DCMAKE_BUILD_TYPE=Debug to generate the build tree then cmake_install.cmake defaults to Debug. Furthermore the file names it references are from the debug configuration.

Are you trying to generate both configurations in a single build tree, or are these in separate build trees sharing one source?
(0025719)
Ben Hines   
2011-03-09 13:22   
Separate build trees with one source.
(0025720)
Brad King   
2011-03-09 13:26   
Strange. I still cannot reproduce that. Can you please attach a tarball with a minimum CMakeLists.txt file (and supporting files) that shows the problem?
(0025721)
Ben Hines   
2011-03-09 13:27   
Working on that now. I'll attach it in a few minutes.
(0025722)
Ben Hines   
2011-03-09 13:37   
OK. I've uploaded a tarball for you... Here's what to do to see the issue
- untar the archive
- cd into the _build/linux/debug directory
- run the script: ../../../setup_linux_debug.sh
- make
- make install

And you get the error I'm talking about. The CMakeList.txt files are pretty simple. I'm hoping I haven't messed anything up in one of those.
(0025723)
Brad King   
2011-03-09 14:21   
The CMakeCache.txt in that tarball indicates you are using CMake 2.8.2, not 2.8.4 as you indicated in the "Product Version" field. This lead me astray in trying to reproduce it. This issue was reported for 2.8.2 already as 0010202. It was fixed for 2.8.3 (and still works in 2.8.4).