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

[Eric Noulard]

2010/8/2 Clinton Stimpson <clinton at elemtech.com>:
> On 08/02/2010 08:22 AM, Clinton Stimpson wrote:
>> On Aug 2, 2010, at 5:29 AM, Eric Noulard wrote:
>>> Waiting for feedback before going on
>>
>> So I wondered if we were basically getting 3 modes out of this:
>>
>> 1. put multiple components in one components aware package (nsis,
>> packagemaker,...).
>> 2. put multiple components in one non-component aware package (tar.gz,
>> .zip...).
>> 3. put multiple components in multiple packages (all cpack generators).
>>
>> And how does one choose the behavior they want?
>
> Also, I wondered if one could choose which components they want to go in the
> package for #2, > and which components go into which packages in #3.

You may do that using COMPONENT GROUPs
(http://www.itk.org/Wiki/CMake:Component_Install_With_CPack#Grouping_Components)
which is not handled in my current patch proposal.

Currently (and for ArchiveGenerator)
A) 1 component == 1 package file
but we can easily translate that into:
B) 1 component group (which is composed of several component) == 1 package file
The trouble with this second option is that you have to ensure that
1 component is only part of a single group. I'm not sure (not tested yet)
it is currently the case "by design".

In the end we may offer the user some CPACK_COMPONENT_IGNORE_COMPONENT_GROUP
in order to enforce A) with the default being B).

> Right now, there is no choice in #2.  Also, for #3, would I be able to choose to
> have 2 required components in one .tar.gz, and each optional component in
> their own tar.gz file.

Using COMPONENT GROUP
would be perfectly suited for that (once it is supported by the
concerned generators)

> I also saw in the patch that the multi-filenames were being pushed up into
> the generators.  I wondered if some component logic and filenames can remain
> in the base class, and generator subclass functions called multiple times
> for each file with a list of components to include.

This is pretty much what I did for ArchiveGenerator but the roots of letting
the specific generator decide the list of packages is done in order
to solve another problem which is the "naming convention" of specific
packages like RPM or DEB, which may be different from NSIS or PackageMaker
etc... see e.g.:
http://public.kitware.com/Bug/view.php?id=9900
http://public.kitware.com/Bug/view.php?id=9932
http://public.kitware.com/Bug/view.php?id=11050

Letting the specific generator "decide" the names and the numbers of
packages to generate is the best we can do to tackle the discrepancy
of capabilities
between generators (those which can do #1 vs #3 vs #2)
without incurring to much pain to the generic root generator.

I should add that there is another thing that only specific generator can do
is to properly describe the dependencies between those multiple package
using the Generator-Agnostic Inter-Component Dependencies description
(even if we have
http://www.itk.org/Wiki/CMake:Component_Install_With_CPack#Intercomponent_Dependencies).
In this case the specific generator MUST know the whole set of package
it will generates.

> It seems that would also be a step towards fixing
> http://public.kitware.com/Bug/view.php?id=10130.

I think this one may be solved using COMPONENT GROUP but I have to
check before being sure of that.

> But I'm sure you had some thoughts too, and maybe a different way to include
> functionality I'm hoping for.

My primary thought was to enable more flexibility for the specific generator,
because I think we cannot find the one-size-fits-all solutions because:

  - the number of generated packages depends on the generator capabilities
  - the fact that the file name of the generated package is not currently
    chosen by the specific generator is already a pain.

Now your request
http://public.kitware.com/Bug/view.php?id=10130
of being able to group things for what you called "non component
aware" generator
is noted (and I did add some links between bugs because I didn't see that one
in the first place...).

Do you think that the 2 solutions:

A) 1 package file per component.
    This may be enforced for some generators by telling!
    set(CPACK_COMPONENT_IGNORE_COMPONENT_GROUP "TGZ;ZIP")

B) 1 package file per component group
    The default behavior.

would be enough to suits your needs?


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