|
Notes |
|
|
(0025747)
|
|
Martin Konrad
|
|
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
|
|
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
|
|
2011-03-31 18:01
|
|
|
Please have a look at the patches I uploaded. |
|
|
|
(0026022)
|
|
Eric NOULARD
|
|
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
|
|
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
|
|
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
|
|
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
|
|
2011-04-06 08:46
|
|
|
Thanks for clarification. This seems to make things much more complicated :-( |
|
|
|
(0026120)
|
|
Eric NOULARD
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
2011-05-26 10:50
|
|
|
Not for 2.8.5 - postponing until a future release |
|
|
|
(0038767)
|
|
Domen Vrankar
|
|
2015-05-18 11:39
|
|
|
|
|
(0040082)
|
|
Robert Maynard
|
|
2016-01-04 11:51
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
0002-Add-inter-component-group-dependencies-to-component-.patch (4,321) 2011-03-31 18:00