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

- Relationships Relation Graph ] Dependency Graph ]
related to 0010781closedKitware Robot CPack infinite recursion with include 
related to 0010067closedEric NOULARD Improve CPack documentation 
related to 0011808closedKitware Robot Make CPack preinstall to take account current install project name 

-  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


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker