MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014634CMakeCMakepublic2013-12-06 07:302016-06-10 14:31
ReporterStephen Kelly 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 3.0 
Target VersionFixed in Version 
Summary0014634: Setting CMAKE_BUILD_TYPE in a subdirectory breaks installation of exported targets.
Descriptionstephen@hal:~/dev/src/kf5/tier1/build{frameworks}$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8.12)

project(myproj)

add_subdirectory(src)
Qt( base ) KDE ( )
stephen@hal:~/dev/src/kf5/tier1/build{frameworks}$ cat ../src/CMakeLists.txt

set(CMAKE_BUILD_TYPE RelWithDebInfo)

add_library(Foo SHARED foo.cpp)

install(TARGETS Foo EXPORT FooTargets DESTINATION lib)

install(EXPORT FooTargets DESTINATION "lib/cmake/Foo" FILE FooTargets.cmake NAMESPACE KF5:: )
Qt( base ) KDE ( )
stephen@hal:~/dev/src/kf5/tier1/build{frameworks}$ rm -rf *
Qt( base ) KDE ( )
stephen@hal:~/dev/src/kf5/tier1/build{frameworks}$ cmake .. -DCMAKE_INSTALL_PREFIX=prefix
-- The C compiler identification is GNU 4.8.1
-- The CXX compiler identification is GNU 4.8.1
-- Check for working C compiler: /usr/lib/icecc/bin/cc
-- Check for working C compiler: /usr/lib/icecc/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/icecc/bin/c++
-- Check for working CXX compiler: /usr/lib/icecc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/stephen/dev/src/kf5/tier1/build
Qt( base ) KDE ( )
stephen@hal:~/dev/src/kf5/tier1/build{frameworks}$ make
makeobj[0]: Entering directory `/home/stephen/dev/src/kf5/tier1/build'
Scanning dependencies of target Foo
[100%] Building CXX object src/CMakeFiles/Foo.dir/foo.cpp.o
Linking CXX shared library libFoo.so
[100%] Built target Foo
makeobj[0]: Leaving directory `/home/stephen/dev/src/kf5/tier1/build'
Qt( base ) KDE ( )
stephen@hal:~/dev/src/kf5/tier1/build{frameworks}$ mi
makeobj[0]: Entering directory `/home/stephen/dev/src/kf5/tier1/build'
[100%] Built target Foo
Install the project...
-- Install configuration: ""
-- Installing: /home/stephen/dev/src/kf5/tier1/build/prefix/lib/libFoo.so
-- Installing: /home/stephen/dev/src/kf5/tier1/build/prefix/lib/cmake/Foo/FooTargets.cmake
makeobj[0]: Leaving directory `/home/stephen/dev/src/kf5/tier1/build'


No config-specific FooTargets-*.cmake file is installed, so the installation is not usable.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-12-06 07:30Stephen KellyNew Issue
2013-12-09 15:03kentwilliamsNote Added: 0034768
2014-08-23 21:49Andreas SchäferNote Added: 0036670
2014-08-23 21:49Andreas SchäferNote Edited: 0036670bug_revision_view_page.php?bugnote_id=36670#r1558
2016-06-10 14:29Kitware RobotNote Added: 0042444
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0034768)
kentwilliams   
2013-12-09 15:03   
The simple answer is "Don't do that!"

The CMAKE_BUILD_TYPE is meant to be set at configure time, in Cmake-gui, ccmake or cmake. It is sort of a 'magic' CMake variable, as it gets defined by CMake even if you never define it. What you're doing might work if you follow the example below; it should be a Cache variable.

It should probably be set in the top-level CMakeLists.txt because clashing redefinitions in subdirectories will cause trouble, especially on Windows because the build type affects library names and output directories.

The following CMake fragment is what is done in ITK. This is in the top level CMakeLists.txt file, but I don't know how much it matters.
#-----------------------------------------------------------------------------
# Set a default build type if none was specified
if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
  message(STATUS "Setting build type to 'Release' as none was specified.")
  set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build." FORCE)
  # Set the possible values of build type for cmake-gui
  set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
endif()
(0036670)
Andreas Schäfer   
2014-08-23 21:49   
Well, this behaviour is not quite intuitive for users. I just spent one day debugging my CMake scripts as I thought /my/ code was broken, not CMake's code.

If you're not going to fix this, then it would be nice if CMake would at least yell at end users if they're setting the build type from an illegal location.

BTW: the bug is also present in CMake 2.8.12.2.
(0042444)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.