Notes
(0021483) Eric NOULARD (developer) 2010-07-26 15:11	CPack.cmaken the file include by include(CPack) contains a lot of cpack_set_if_not_set which set variables to default values if the concerned variables is not set (most of the time by the user file calling include(CPack)) so I do not think that including CPack twice in the same CMakeLists.txt have a clearly defined behavior. The reason of what you see is probably due to the fact that CPack.cmake set CPACK_INSTALLED_DIRECTORIES SET(CPACK_INSTALLED_DIRECTORIES "${CPACK_SOURCE_INSTALLED_DIRECTORIES}") just before generating the source cpack config file. Thus on the second inclusion of CPack the variable is defined with the value meant for the CPack source generator. include(CPack) is not a pure "function" call, it has side effects. By the way, what are you trying/wanting to do?

(0021484) Clinton Stimpson (developer) 2010-07-26 15:19	If one does an add_subdirectory to include a project that can be stand-alone (and has its own cpack stuff), it could potentially cause interference. Also, one could choose to package up a project into multiple packages. I see that on Linux distros where they divide up the cmake project into multiple .deb/.rpm packages.

(0021485) Eric NOULARD (developer) 2010-07-26 15:34	OK I see, my opinion is: 1) For add_subdirectory, this is a bug. However I'm surprised that no-one hit this. I would suspect that either people adding a project as sub directorty would change the main CMakeLists.txt for that or using ExternalProject_Add which shouldn't have this problem. 2) Concerning the splitting of software into multiple packages the appropriate way to go (my opinion) should be to use CPack Components http://www.itk.org/Wiki/CMake:Component_Install_With_CPack [^] The current drawback is that not that many installers supports components...there is a bunch of bug report concerning this.

(0021881) Eric NOULARD (developer) 2010-08-22 12:37	Related ML thread http://www.cmake.org/pipermail/cmake/2010-August/038648.html [^]

(0021882) Eric NOULARD (developer) 2010-08-22 12:53	I think the best idea up to now is the one given by Alex: http://www.cmake.org/pipermail/cmake/2010-August/038678.html [^] Quoting here for easing the reminder: > My personal point of view with your idea is that > since we most most probably want to maintain backward compatibility > it would even be better if we can do > > 1 - set(CPACK_... > 2 - include(CPack) > 3 - set(CPACK_...) > 4 - cpack_update_config() or cpack_reconfig() > > that way 1, 3 and 4 are optional just as today. > 3 and 4 would bring what you suggest. Maybe this should be then more something like: 1 - set(CPACK_... 2 - include(UseCPack) 3 - set(CPACK_...) 4 - cpack_configure() where UseCPack.cmake would contain just a part of the current CPack.cmake, i.e. the part which sets the default values, which would be split out into a file shared by both CPack.cmake and UseCPack.cmake, and a macro/function which then actually generates the files for cpack. This way it should be possible to avoid any backwards compatibility issues. Alex

(0025591) Eric NOULARD (developer) 2011-02-27 17:31	Hi Dave, I think we should support some sort of what was suggested by Alex. I did begin to split-up the Monolithic CPack.cmake in several pieces, see CPack-ModularizeCPack branch on stage. I think that having some CPack<Whatever>.cmake containing only macros. CPackDefaultValues.cmake containing the current default values definitions used in CPack.cmake. UseCPack.cmake containing the appropriate sequence of include(CPack<Whatever>) and CPack.cmake a backward compatible version using previous files. We should manage to: 1) Have a smaller CPack.cmake which is currently ridiculously long 2) Support multi-package generation 3) Beginning of a better doc due to the split. What do you think?

(0030612) David Cole (manager) 2012-08-13 15:16	Sending old, not-recently-updated issues to the backlog. (The age of the bug alone means that nobody is actively working on it...) If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^] It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.

(0041703) Kitware Robot (administrator) 2016-06-10 14:28	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-05-24 12:15	Clinton Stimpson	New Issue
2010-07-26 15:11	Eric NOULARD	Note Added: 0021483
2010-07-26 15:19	Clinton Stimpson	Note Added: 0021484
2010-07-26 15:34	Eric NOULARD	Note Added: 0021485
2010-07-29 09:05	Eric NOULARD	Relationship added	related to 0010781
2010-08-22 12:37	Eric NOULARD	Note Added: 0021881
2010-08-22 12:53	Eric NOULARD	Note Added: 0021882
2010-12-14 18:39	David Cole	Assigned To	=> David Cole
2010-12-14 18:39	David Cole	Status	new => assigned
2011-02-07 02:00	Eric NOULARD	Relationship added	related to 0011808
2011-02-27 17:31	Eric NOULARD	Note Added: 0025591
2011-02-27 17:31	Eric NOULARD	Relationship added	related to 0010067
2012-08-13 15:16	David Cole	Status	assigned => backlog
2012-08-13 15:16	David Cole	Note Added: 0030612
2012-08-13 15:17	David Cole	Assigned To	David Cole =>
2016-06-10 14:28	Kitware Robot	Note Added: 0041703
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:28	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed