Notes |
|
(0020351)
|
XU Liang
|
2010-04-22 11:13
|
|
Maybe we can generate a tar that include all component RPMs.
What can I help this issue? |
|
|
(0020365)
|
Eric NOULARD
|
2010-04-22 18:09
|
|
I'm not sure to understand your proposal but
bundling all components in a single tar that
would get put in a single RPM wouldn't seem like
a component to me?
Again may be I'm wrong, what do you propose to do? |
|
|
(0020387)
|
XU Liang
|
2010-04-24 11:01
|
|
Sorry for my bad English.
My propose is we can generate some RPMs that bundle a single component, then we pack all RPMs to a single tar. it's a work-around solution. |
|
|
(0021441)
|
Eric NOULARD
|
2010-07-21 13:33
|
|
The problem of naming the package filename produced by CPack
is poppin-up again and again on the ML:
The name of the package file is currently driven by the value of
CPACK_PACKAGE_FILE_NAME (this the name of the file without the extension).
If the user does not set this variable CPack.cmake is setting it to be
${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}
The user may override this name inside its CMakeLists.txt.
Whatever the solution, specific generator (RPM, DEB, TGZ etc...)
may not currently change the name. This is the root of the issue
because sometimes the name convention may be different depending
on the package type (e.g. .deb and .rpm have different naming convention). |
|
|
(0021871)
|
Eric NOULARD
|
2010-08-21 08:30
|
|
CPack-APIredesign branch has been merged to master
commit cc2ba7f9c283a28804967820fa8f212f630d6aa8
Merge: 57c5bf5 bd510fe
Author: Brad King <brad.king@kitware.com>
Date: Tue Aug 17 15:12:42 2010 -0400
Merge topic 'CPack-APIredesign'
bd510fe CPack: Avoid member shadowing after API refactor (part2)
31a313d CPack: Avoid member shadowing after API refactor
cd7b8a0 CPack: Refactor API in order to handle multi-file packages
This makes it possible to let the specific generator decide the number
and the name of the generated packages. |
|