MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010751CMakeModulespublic2010-05-24 12:152016-06-10 14:31
ReporterClinton Stimpson 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0010751: CPack.cmake confused when used twice
Descriptionset(CPACK_OUTPUT_CONFIG_FILE myconfig1.cmake)
include(CPack)

set(CPACK_OUTPUT_CONFIG_FILE myconfig2.cmake)
include(CPack)

I'd expect myconfig1.cmake and myconfig2.cmake to be equivalent, but they are not. myconfig2.cmake packages up the source tree instead of relying on install() commands.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0010781closed Kitware Robot CPack infinite recursion with include 
related to 0010067closed Eric NOULARD Improve CPack documentation 
related to 0011808closed Kitware Robot Make CPack preinstall to take account current install project name 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-05-24 12:15Clinton StimpsonNew Issue
2010-07-26 15:11Eric NOULARDNote Added: 0021483
2010-07-26 15:19Clinton StimpsonNote Added: 0021484
2010-07-26 15:34Eric NOULARDNote Added: 0021485
2010-07-29 09:05Eric NOULARDRelationship addedrelated to 0010781
2010-08-22 12:37Eric NOULARDNote Added: 0021881
2010-08-22 12:53Eric NOULARDNote Added: 0021882
2010-12-14 18:39David ColeAssigned To => David Cole
2010-12-14 18:39David ColeStatusnew => assigned
2011-02-07 02:00Eric NOULARDRelationship addedrelated to 0011808
2011-02-27 17:31Eric NOULARDNote Added: 0025591
2011-02-27 17:31Eric NOULARDRelationship addedrelated to 0010067
2012-08-13 15:16David ColeStatusassigned => backlog
2012-08-13 15:16David ColeNote Added: 0030612
2012-08-13 15:17David ColeAssigned ToDavid Cole =>
2016-06-10 14:28Kitware RobotNote Added: 0041703
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0021483)
Eric NOULARD   
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   
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   
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   
2010-08-22 12:37   
Related ML thread
http://www.cmake.org/pipermail/cmake/2010-August/038648.html [^]
(0021882)
Eric NOULARD   
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   
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   
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   
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.