On Monday, August 02, 2010 05:28:10 pm Eric Noulard wrote:
> 2010/8/2 Clinton Stimpson <clin...@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_Compon
> ents) 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_D
> ependencies). 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?
That bug report is basically asking that CPACK_COMPONENTS_ALL work for all
cpack generators like it does for NSIS and PackageMaker.
If it did, then I could avoid writing code like this:
if(devel_install)
install(.... COMPONENT Runtime
.... COMPONENT Development
)
else()
install(... COMPONENT Runtime)
endif()
And simply do this:
install(.... COMPONENT Runtime
.... COMPONENT Development
)
Then control the packaging of components with the cpack config file.
I've added comments to that bug to clarify.
I guess it isn't directly related to multi-file packaging.
But since multi-file packaging was brought up, I thought it might be nice to
have control over which files are created as well as which components go into
which files, so then it could be related.
Your B) solution sounds fine.
Thanks,
Clint
_______________________________________________
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
