View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011944CMakeCPackpublic2011-03-09 08:292016-01-04 11:51
ReporterMartin Konrad 
Assigned ToRaffi Enficiaud 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in VersionCMake 3.3 
Summary0011944: CPackDeb: Support dependencies between components/Debian packages
DescriptionThe patch provided in 0011655 does not transform the dependencies between CMake components into dependencies between the resulting Debian packages.
TagsNo tags attached.
Attached Filespatch file icon 0002-Add-inter-component-group-dependencies-to-component-.patch [^] (4,321 bytes) 2011-03-31 18:00 [Show Content]
patch file icon 0003-CPackDeb-Add-support-for-automatic-package-dependenc.patch [^] (3,464 bytes) 2011-03-31 18:00 [Show Content]
patch file icon 0001-Add-inter-component-group-dependencies-to-component-.patch [^] (5,032 bytes) 2011-04-01 13:56 [Show Content]
patch file icon 0001-CPackDeb-Add-support-for-automatic-package-dependenc.patch [^] (3,446 bytes) 2011-04-06 06:04 [Show Content]

 Relationships
parent of 0013231closedRaffi Enficiaud CPackDeb incorrectly "leaks" Debian dependencies across components 

  Notes
(0025747)
Martin Konrad (reporter)
2011-03-10 15:27

Here are some ideas about how to handle intercomponent dependencies:
-dependencies between components are specified explicitly in CMakeLists.txt (e.g. "set(CPACK_COMPONENT_APPLICATIONS_DEPENDS libraries)")
-dependencies between component _groups_:
    loop over all components in the current component group {
        loop over all component names the current component depends on {
            get the component object from the component name
            find out the component group for the component we depend on
            add the component group to the list of component groups the current component group depends on
        }
    }
-dependencies between packages are the same as between component groups

I think that should be easy to implement. - Except for one step which is not that obvious to me: How do I get the component object from the component name? Unfortunately I cannot use the method

cmCPackGenerator::GetComponent(const char *projectName, const char *name)

because I don't have the project name in cmCPackDebGenerator. Did I miss something?
(0025754)
Eric NOULARD (developer)
2011-03-10 16:48

The
CPackGenerator::Components
protected field (accessible in CPackDebGenerator)
is a map whose key is the component name.

So you can do:

cmCPackComponent comp = Components["the-name"]
or directly

Components["the-name"].Dependencies

etc...

in the same way for Component Groups you have:

CPackGenerator::ComponentGroups
protected field.

Dependencies should have been set up by
cmCPackGenerator::GetComponent.

Group dependencies may be computed using component
dependencies, may be we could add some method and fields in
ComponentGroups for that.
(0026001)
Martin Konrad (reporter)
2011-03-31 18:01

Please have a look at the patches I uploaded.
(0026022)
Eric NOULARD (developer)
2011-04-01 14:15

Hi Martin,

Thank you very much for your patch.
Small remarks:

1) Try to respect KWStyle source code format which mainly implies
   - no space at the end of line
   - no line length greater than 80 columns
   You may enforce this on local commit by setting up a kwstyle local hook:
   see http://www.cmake.org/Wiki/Git/Hooks [^]

2) Current master has changed merging many things in the CPack area
   including your first patch for the support of Component with CPackDeb
   (and the latest fix), but there more changes.

   Could you please rebase your patch on current master, it will be
   easier for me to review and merge.
   I did it for the first patch a attached it to the tracker.
   You create a brand new branch
    $ git pull
    $ git checkout -b CPack-ComputeGroupDependencies origin/master
   and apply the patch.

   I let you do it for the second patch, because as you will soon
   discover I did some refactoring in CPackDeb (and CPackRPM) in order
   to avoid code duplication.
 
3) Concerning the content of the patch it looks good but you did not
   handle the case of "left over components", that is some component
   may not belong to **any** group, so in this case the dependency
   should be between a group and a component (which will be packaged
   in its own file because it's orphan).
   I did add some "FIXME" inside the updated patch where the problem
   may occur.

4) May be we should update the CPackComponentForAll test example
   with dependencies in order to have a test which checks that
   all the dependency cases are properly handled.

Thanks for your work.
I think you are on track for making this go in CMake 2.8.5,
moreover it will certainly help me a lot for doing it for CPackRPM.
(0026101)
Eric NOULARD (developer)
2011-04-05 16:02

Hi Martin,

Tuesday is the next to master merge.
Today's round came with its change in the CPack area too.
When you continue to work on this try to rebase your work
on current master.

Sorry for this endless stay-up-to-date loop,
if you find it painful I'll try to update your patch myself.
(0026116)
Martin Konrad (reporter)
2011-04-06 08:00

Hi Eric,
thanks for your reply.

1) Seems I somehow broke my local commit hooks :-(
2) I'm still learning git. So thanks for your help. I just uploaded a rebased version of the patch (without the "FIXME" lines).
3/4) I don't understand this issue completely. In the OnePackPerGroup case "left over components" are packaged into another file (e.g. MyLib-1.0.2-Linux-Unspecified.deb), aren't they? Doesn't that mean we have another (automatically generated) component group "Unspecified"? Can you please provide an example/test case for clarification?
(0026118)
Eric NOULARD (developer)
2011-04-06 08:13

3/4)

There are 2 kind of "left over":

a) Component which are specified in INSTALL(... COMPONENT Toto)
  but does not belong to any component group.
  i.e. there is no
  set(CPACK_COMPONENT_<GROUPNAME>_GROUP "Toto")
  In that case if you require OnePackPerGroup then the Toto
  component will be packaged in its own "component" package file.

b) INSTALL(....) rules which does not specify COMPONENT
   in this case CMake creates put the INSTALLed thing in
   the "Unspecified" component. This "Unspecified" component
   may or may not (usual default case) belong to a component group.

The dependencies are specified at COMPONENT level so you
may find a dependence between a COMPONENT GROUP and a
COMPONENT which does not belong to any group.

Is it clearer, stated this way?

PS: in the current CPackComponentForAll test "Unspecified"
contains some target AND is a left over component not belonging
to any group.
(0026119)
Martin Konrad (reporter)
2011-04-06 08:46

Thanks for clarification. This seems to make things much more complicated :-(
(0026120)
Eric NOULARD (developer)
2011-04-06 08:52

No I don't think so.
You may "just" add the fact that a dependency may be between
a GROUP and a COMPONENT.

Or create a "fake" component group with the same name as
the lonely component.
(0026131)
Martin Konrad (reporter)
2011-04-07 05:56

3/4 b) There are two cases:
1. The "Unspecified" component depends on some other component group. The CPackComponentForAll OnePackPerGroup test seems to cover a case like this (no component specified for target mylibapp2). The "Unspecified" component depends on the component "libraries" which is part of the component group "Development".
2. Some other component group depends on the "Unspecified" component.
(0026132)
Martin Konrad (reporter)
2011-04-07 06:14

I'm still fighting with the details of those (in my opinion much to complicated) rules about stuff that does not belong to any component or component group. And it seems this will take much more time than I have currently :-( So perhaps someone else can help?
(0026133)
Eric NOULARD (developer)
2011-04-07 08:46

Hi Martin,

You are right about the two cases.
I would bet that the case where a group depends on the "Unspecified"
shouldn't be a practical case.

We can try to simplifies things by "just" letting the pathological cases
dependencies unresolved and come back to it later
when more spare time (for you or me or anybody else) opens up.

In any case if you do not have enough time now,
post your latest patch on the tracker and I'll take over.
(0026143)
Martin Konrad (reporter)
2011-04-07 15:52

Hi Eric,
my latest code can be found in 0001-CPackDeb-Add-support-for-automatic-package-dependenc.patch
(0026620)
David Cole (manager)
2011-05-26 10:50

Not for 2.8.5 - postponing until a future release
(0038767)
Domen Vrankar (developer)
2015-05-18 11:39

Resolved by commit:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=e3f522f [^]
(0040082)
Robert Maynard (manager)
2016-01-04 11:51

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2011-03-09 08:29 Martin Konrad New Issue
2011-03-09 09:28 Eric NOULARD Assigned To => Eric NOULARD
2011-03-09 09:28 Eric NOULARD Status new => assigned
2011-03-10 15:27 Martin Konrad Note Added: 0025747
2011-03-10 16:48 Eric NOULARD Note Added: 0025754
2011-03-11 02:51 Eric NOULARD Product Version => CMake-2-8
2011-03-11 02:51 Eric NOULARD Target Version => CMake 2.8.5
2011-03-31 18:00 Martin Konrad File Added: 0002-Add-inter-component-group-dependencies-to-component-.patch
2011-03-31 18:00 Martin Konrad File Added: 0003-CPackDeb-Add-support-for-automatic-package-dependenc.patch
2011-03-31 18:01 Martin Konrad Note Added: 0026001
2011-04-01 13:56 Eric NOULARD File Added: 0001-Add-inter-component-group-dependencies-to-component-.patch
2011-04-01 14:15 Eric NOULARD Note Added: 0026022
2011-04-05 16:02 Eric NOULARD Note Added: 0026101
2011-04-06 06:04 Martin Konrad File Added: 0001-CPackDeb-Add-support-for-automatic-package-dependenc.patch
2011-04-06 08:00 Martin Konrad Note Added: 0026116
2011-04-06 08:13 Eric NOULARD Note Added: 0026118
2011-04-06 08:46 Martin Konrad Note Added: 0026119
2011-04-06 08:52 Eric NOULARD Note Added: 0026120
2011-04-07 05:56 Martin Konrad Note Added: 0026131
2011-04-07 06:14 Martin Konrad Note Added: 0026132
2011-04-07 08:46 Eric NOULARD Note Added: 0026133
2011-04-07 15:52 Martin Konrad Note Added: 0026143
2011-05-26 10:50 David Cole Note Added: 0026620
2011-05-26 10:50 David Cole Target Version CMake 2.8.5 =>
2015-04-16 09:43 Raffi Enficiaud Assigned To Eric NOULARD => Raffi Enficiaud
2015-05-14 13:00 Raffi Enficiaud Relationship added parent of 0013231
2015-05-18 11:39 Domen Vrankar Note Added: 0038767
2015-05-18 11:39 Domen Vrankar Status assigned => resolved
2015-05-18 11:39 Domen Vrankar Fixed in Version => CMake 3.3
2015-05-18 11:39 Domen Vrankar Resolution open => fixed
2016-01-04 11:51 Robert Maynard Note Added: 0040082
2016-01-04 11:51 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team