2010/8/2 Clinton Stimpson <[email protected]>: > 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 _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
