MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012906CMakeCPackpublic2012-01-20 16:552013-01-09 10:55
ReporterK. R. Walker 
Assigned ToEric NOULARD 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 2.8.7 
Target VersionCMake 2.8.9Fixed in VersionCMake 2.8.9 
Summary0012906: CPACK_PACKAGE_DIRECTORY in CPackConfig.cmake is not respected
DescriptionThe CPack project directory (command-line argument '-B' a.k.a. CPACK_PACKAGE_DIRECTORY) cannot be set in CMake code and be respected.

CMake writes out the CPACK_PACKAGE_DIRECTORY variable in CPackConfig.cmake, but when:
  cpack --config ./CPackConfig.cmake
is run from the package target, cpack.cxx does the following:

1. Variable cpackProjectDirectory is initialized from GetCurrentWorkingDirectory() (line 151)

2. The CPackConfig.cmake file is used to sets globalMF variables (line 272)

3. Because cpackProjectDirectory is not empty (line 306), the value of this is then inserted into globalMF as CPACK_PACKAGE_DIRECTORY. This overwrites the value that was in the CPackConfig.cmake file.


CPACK_PACKAGE_DIRECTORY should not be set to the value of GetCurrentWorkingDirectory() unless it's not set by line 321 (just after -D variables have been inserted into globalMF).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespatch 0001-Do-not-provide-defaul-value-for-CPACK_PACKAGE_DIRECT.patch (2,599) 2012-07-04 17:12
https://public.kitware.com/Bug/file/4377/0001-Do-not-provide-defaul-value-for-CPACK_PACKAGE_DIRECT.patch
Issue History
Date ModifiedUsernameFieldChange
2012-01-20 16:55K. R. WalkerNew Issue
2012-07-04 10:50Florian RamillienNote Added: 0029904
2012-07-04 11:52Florian RamillienNote Added: 0029906
2012-07-04 16:41Eric NOULARDNote Added: 0029907
2012-07-04 16:41Eric NOULARDAssigned To => Eric NOULARD
2012-07-04 16:41Eric NOULARDStatusnew => assigned
2012-07-04 17:12Eric NOULARDFile Added: 0001-Do-not-provide-defaul-value-for-CPACK_PACKAGE_DIRECT.patch
2012-07-04 17:16Eric NOULARDNote Added: 0029908
2012-07-05 04:58Florian RamillienNote Added: 0029913
2012-07-05 05:13Eric NOULARDNote Edited: 0029907bug_revision_view_page.php?bugnote_id=29907#r732
2012-07-05 05:19Eric NOULARDNote Added: 0029914
2012-07-05 05:19Eric NOULARDNote Added: 0029915
2012-07-05 05:19Eric NOULARDStatusassigned => resolved
2012-07-05 05:19Eric NOULARDResolutionopen => fixed
2012-08-09 16:50David ColeFixed in Version => CMake 2.8.9
2012-08-09 16:50David ColeTarget Version => CMake 2.8.9
2013-01-09 10:55Robert MaynardNote Added: 0032013
2013-01-09 10:55Robert MaynardStatusresolved => closed

Notes
(0029904)
Florian Ramillien   
2012-07-04 10:50   
Confirm presence of this problem in CMake 2.8.8
(0029906)
Florian Ramillien   
2012-07-04 11:52   
I try to find a work around. I expect to do it in Cmake script, since the product version is actually only known by CMAKE.

I begin with :

---

set (CPACK_PACKAGE_VERSION_MAJOR "${MyProduct_VERSION_MAJOR}")
set (CPACK_PACKAGE_VERSION_MINOR "${MyProduct_VERSION_MINOR}")
set (CPACK_PACKAGE_DIRECTORY "$ENV{MY_NEXUS_PATH}/MyProduct/${MyProduct_VERSION_MAJOR}.${MyProduct_VERSION_MINOR}.${MyProduct_VERSION_PATCH}")

INCLUDE(CPack)

add_custom_target(post_package
    COMMAND ${CMAKE_COMMAND} -E copy ${CPACK_PACKAGE_FILE_NAME} ${CPACK_PACKAGE_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}
    )
ADD_DEPENDENCIES(post_package package)

---

But CPACK_PACKAGE_FILE_NAME contain the "source" package name, not the release one. I can rebuilt the package name, but it's not a good solution. Any other variable usefull for this ?

Thanks.
(0029907)
Eric NOULARD   
2012-07-04 16:41   
(edited on: 2012-07-05 05:13)
Hi Florian,

I think your problem is different from the one explained in this bug report.
see for 0012997 which is more directly linked to package name handling.

Concerning the initial bug I'll post a patch right after that message.
(0029908)
Eric NOULARD   
2012-07-04 17:16   
Hi,

the attached patch
(or the branch stage/CPack-honorCPACK_XXX-valuesInScriptFile)

Should fix this issue.
The patch adds builtin doc for CPACK_PACKAGE_DIRECTORY.

I did not push to next because I have to think about it a little more
in order to think whether if the new behavior could break existing behavior.

The behavior should now be to define CPACK_PACKAGE_DIRECTORY value:

1) using -B command line option argument
2) use value in config file (if one is found)
3) use current directory i.E. build dir if none of the previous defines it.

This means that -B command line option will override a value set
in a config file.

Would this be the expected behavior?
Would you try the patch please.
(0029913)
Florian Ramillien   
2012-07-05 04:58   
Thanks for the quick answer. The patch works fine.

- CPACK_PACKAGE_DIRECTORY not defined : default value used
- CPACK_PACKAGE_DIRECTORY defined : specified path used
- -B on cpack command line : override default and CPACK_PACKAGE_DIRECTORY values

About the behaviour, I agree with you, command line parameters should take precedence on configuration parameters.
(0029914)
Eric NOULARD   
2012-07-05 05:19   
Ok,
Florian: Thank you for testing.

After more deeper thought I don't think this modification could break existing
project because no one usually set CPACK_PACKAGE_DIRECTORY in its project
and if it does he would have discovered that this does not work as expected
like the initial reporter did.

Just merged it to next:
Fetching upstream next
Merge topic 'CPack-honorCPACK_XXX-valuesInScriptFile' into next

05a8630 Do not provide defaul value for CPACK_PACKAGE_DIRECTORY if found in config.

For Kitware developers:
Nevertheless, it could be wise not to put that in 2.8.9 in order to give
more time for testing.

That said if we plan more than one RC, putting this in the next RC
may be good enough.
(0029915)
Eric NOULARD   
2012-07-05 05:19   
See previous comment
(0032013)
Robert Maynard   
2013-01-09 10:55   
Closing resolved issues that have not been updated in more than 4 months.