|
Notes |
|
|
(0028447)
|
|
Eric NOULARD
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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. |
|