View Issue Details Jump to Notes ] Print ]
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.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0034768)
kentwilliams (reporter)
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 (reporter)
2014-08-23 21:49
edited on: 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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2013-12-06 07:30 Stephen Kelly New Issue
2013-12-09 15:03 kentwilliams Note Added: 0034768
2014-08-23 21:49 Andreas Schäfer Note Added: 0036670
2014-08-23 21:49 Andreas Schäfer Note Edited: 0036670
2016-06-10 14:29 Kitware Robot Note Added: 0042444
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team