[cmake-developers] [CMake] Support for multiple components in cpack

Eric Noulard eric.noulard at gmail.com
Fri Aug 6 07:08:01 EDT 2010


2010/8/6 Clinton Stimpson <clinton at elemtech.com>:
> On Thursday, August 05, 2010 04:46:01 pm Eric Noulard wrote:
>> 2010/8/3 Eric Noulard <eric.noulard at gmail.com>:
>> > 2010/8/3 David Cole <david.cole at kitware.com>:
>> >> On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard <eric.noulard at gmail.com>
> wrote:
>> >>> 2. may always be an option because it was the behavior we had before
>> >>> the component support and ALL CPack generator may handle an all-in-one
>> >>> package.
>> >>> We could add an OPTION like CPACK_COMPONENT_ALL_IN_ONE which
>> >>> would basically tell CPack to ignore the component aspect.
>> >>
>> >> FYI: there already is an option that's similar to this, I
>> >> think: CPACK_MONOLITHIC_INSTALL
>> >> Does that have the effect you're talking about or are you thinking
>> >> something different?
>> >
>> > You are right that's the idea.
>> > I wasn't aware of that option... I'll go for a thorough read of
>> > CPack.cmake documentation
>> > before re-inventing existing options...
>>
>> After a remark made by Clint and some thought.
>>
>> CPACK_MONOLITHIC_INSTALL is not covering the whole need
>> and I think we need a
>> CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE options.
>>
>> Have a look at the updated bug entry and the description of
>> all cases:
>> http://public.kitware.com/Bug/view.php?id=10736
>>
>> There is a fifth patch to the current patchset to propose that.
>>
>> Clint would you be able to give it a try and tell us if with
>> this last patch (still cumulative) your needs are covered?
>
> Here's my test case
> =====
> file(WRITE file.txt.in "hi")
>
> configure_file(file.txt.in ${CMAKE_CURRENT_BINARY_DIR}/file-runtime.txt)
> configure_file(file.txt.in ${CMAKE_CURRENT_BINARY_DIR}/file-devel.txt)
>
> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file-runtime.txt
>        DESTINATION bin COMPONENT Runtime)
> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file-devel.txt
>        DESTINATION lib COMPONENT Development)
>
> SET(CPACK_COMPONENTS_ALL Runtime Unspecified)
> set(CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE 1)
> include(CPack)
> ===
>
> $ cpack -G TGZ
> CPack: Create package using TGZ
> CPack: Install projects
> CPack: - Run preinstall target for: Project
> CPack: - Install project: Project
> CPack: -   Install component: Runtime
> CPack: -   Install component: Unspecified
> CPack: Compress package
> CPack: Finalize package
> CPack: Component package: .../Project-0.1.1-Linux-Runtime.tar.gz generated.
> CPack: Component package: .../Project-0.1.1-Linux-Unspecified.tar.gz generated.
>
> Its still multiple files with their component specific names.

Yes that's true. And this is because you did not defined any component GROUP.

> How about instead of adding a CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE
> variable, one just puts the components into a single group.

This will work off course.
But the CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE has a different goal.
You may
  - define any number of COMPONENTS

  - define *any* number of COMPONENTS GROUPS

  - decide which components should be installed using
     CPACK_COMPONENTS_ALL
    [and this will bring the groups to which the components belongs to]

Those first step is the way you would work with a "genuine"
component-aware package installer like NSIS.

Now with the **very same** CMakeLists.txt you may generate
a set of plain archives (tar, zip, etc...)

1) either 1 archive per group (default)
2) either 1 archive per component (CPACK_COMPONENTS_IGNORE_GROUP=1)
3) either 1 archive for all groups
(CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1)

> With your patches, that now gives one .tar.gz file with the selected
> components, which is what I want
> Except now I've got an "-ALL" suffix to the package name, which isn't a big deal
> to me.
> What do you think?

I think I missed the fact that you did not used component GROUPS
at all in the first place :-)

So Yes you may define a single group for all components and the default behavior
will suits your needs.

But now you may even do more and define all the groups you want
as you would do for an NSIS installer
AND

cpack -G NSIS  will produce the expected NSIS package

whereas

cpack -D CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE=1 tgz
will produce the "all groups in one package"

Here is your example updated:
====
cmake_minimum_required(VERSION 2.8)
file(WRITE file.txt.in "hi")

configure_file(file.txt.in ${CMAKE_CURRENT_BINARY_DIR}/file-runtime.txt)
configure_file(file.txt.in ${CMAKE_CURRENT_BINARY_DIR}/file-devel.txt)
configure_file(file.txt.in ${CMAKE_CURRENT_BINARY_DIR}/file-leftover.txt)

install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file-runtime.txt
       DESTINATION bin COMPONENT Runtime)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file-devel.txt
       DESTINATION lib COMPONENT Development)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/file-leftover.txt
       DESTINATION lib COMPONENT Leftover)

set(CPACK_COMPONENT_RUNTIME_GROUP "main")
set(CPACK_COMPONENT_DEVELOPMENT_GROUP "main")
set(CPACK_COMPONENT_LEFTOVER_GROUP "other")

# toggle the 2 followings lines if you want to generate
# the "other" group file.
#SET(CPACK_COMPONENTS_ALL Runtime Development Leftover)
SET(CPACK_COMPONENTS_ALL Runtime Development)

include(CPack)
====
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org



More information about the cmake-developers mailing list