Notes
(0028447) Eric NOULARD (developer) 2012-02-02 04:48	May be an alternative implementation could use env var COMPONENT in the same way DESTDIR is currently used. This could be used like this: make COMPONENT=headers install The sole modification needed would be to add the following code snippet: # User provided component request if ("$ENV{COMPONENT}" STRGREATER "") message(STATUS "User request for component...${COMPONENT}") set(COMPONENT "$ENV{COMPONENT}") endif("$ENV{COMPONENT}" STRGREATER "") at the beginning of all generated "cmake_install.cmake" files. The main drawback compared to Michael approach are: 1) You don't get a new install target so that it may not be easy to use in an IDE 2) You can specify non-existing component. Which will work but install nothing :-( I don't know if 1) is important. 2) may be fixed by generating some checking before setting up COMPONENT.

(0028450) Brad King (manager) 2012-02-02 08:17	I think Eric's approach is pretty simple and will work well for Makefile generators. It's not mutually exclusive with having multiple install-XXX targets in the Makefiles either. One reason I'm hesitant on multiple install-XXX targets (besides cluttering the IDEs) is that there have been numerous feature requests for making the CMake-provided targets like "install" and "clean" into first-class targets. That would allow projects to add their own custom commands and dependencies to such targets. The feature is difficult to define because of the per-directory behavior of such targets in the generated Makefiles. Adding more such targets will only complicate eventual inclusion of the feature. Furthermore I've always thought of component installations to be a feature used by packagers whose scripts can invoke cmake_install.cmake directly with the proper arguments. A nice end-user interface has never been a priority.

(0030633) Alexander Broekhuis (reporter) 2012-08-14 03:51	As an addition/alternative to Eric's proposed solution, why not add the COMPONENT or CMAKE_INSTALL_COMPONENT to the generated Makefile, if it is set? This way the user can: A) Supply the component on the command line B) Set it in the CMake files This allows a user to override the install, but also a possibility to add custom targets by setting the component from cmake.

(0030657) Eric NOULARD (developer) 2012-08-14 17:18	I don't think it would make much sense to set "COMPONENT" inside a CMakeLists.txt. What we could do is to define something like "CMAKE_COMPONENTS_ALL" in order to mimic what "CPACK_COMPONENTS_ALL" currently do. see cpack --help-variable CPACK_COMPONENTS_ALL. CMAKE_COMPONENTS_ALL would contains the list of COMPONENT to be installed if none are specified. Note however that defining such a variable in a CMakeLists.txt may be difficult because COMPONENT are known to CMake after INSTALL commands are processed. Most of the time we won't be able to check whether if the content of CPACK_COMPONENTS_ALL is valid or not.

(0041680) Kitware Robot (administrator) 2016-06-10 14:27	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
2010-04-09 15:21	Michael Wild	New Issue
2010-04-28 09:23	Bill Hoffman	Status	new => assigned
2010-04-28 09:23	Bill Hoffman	Assigned To	=> Brad King
2012-02-02 04:48	Eric NOULARD	Note Added: 0028447
2012-02-02 08:17	Brad King	Note Added: 0028450
2012-02-02 08:17	Brad King	Assigned To	Brad King =>
2012-02-02 08:17	Brad King	Status	assigned => backlog
2012-08-14 03:51	Alexander Broekhuis	Note Added: 0030633
2012-08-14 17:18	Eric NOULARD	Note Added: 0030657
2012-11-10 09:47	Eric NOULARD	Relationship added	related to 0011142
2016-06-10 14:27	Kitware Robot	Note Added: 0041680
2016-06-10 14:27	Kitware Robot	Status	backlog => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:27	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed