View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0011944 | CMake | CPack | public | 2011-03-09 08:29 | 2016-01-04 11:51 | ||||
Reporter | Martin Konrad | ||||||||
Assigned To | Raffi Enficiaud | ||||||||
Priority | normal | Severity | feature | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake-2-8 | ||||||||
Target Version | Fixed in Version | CMake 3.3 | |||||||
Summary | 0011944: CPackDeb: Support dependencies between components/Debian packages | ||||||||
Description | The patch provided in 0011655 does not transform the dependencies between CMake components into dependencies between the resulting Debian packages. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | 0002-Add-inter-component-group-dependencies-to-component-.patch [^] (4,321 bytes) 2011-03-31 18:00 [Show Content]
0003-CPackDeb-Add-support-for-automatic-package-dependenc.patch [^] (3,464 bytes) 2011-03-31 18:00 [Show Content] 0001-Add-inter-component-group-dependencies-to-component-.patch [^] (5,032 bytes) 2011-04-01 13:56 [Show Content] 0001-CPackDeb-Add-support-for-automatic-package-dependenc.patch [^] (3,446 bytes) 2011-04-06 06:04 [Show Content] | ||||||||
Relationships | ||||||
|
Relationships |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |