View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007645CMakeCPackpublic2008-09-10 08:462011-01-05 02:57
ReporterEric NOULARD 
Assigned ToEric NOULARD 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionCMake 2.8.4Fixed in VersionCMake 2.8.4 
Summary0007645: Add support of CPack Component to CPack RPM generator
DescriptionI should be doable to add CPack component support [^]
to CPack RPM.

We could generate 1 RPM for each Component with builtin
appropriate dependencies: [^]

posted here as a reminder.
TagsNo tags attached.
Attached Fileszip file icon [^] (83,422 bytes) 2009-09-19 20:18
? file icon CPackRPM.cmake [^] (21,434 bytes) 2009-09-19 20:19
diff file icon cmake.diff [^] (1,013 bytes) 2009-09-19 20:28 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]
parent of 0011656closedDomen Vrankar CPackRPM: Support dependency between RPM component 
related to 0009900closedEric NOULARD Make CPack generic generator delegate the name of the file to specific generator 
related to 0011655closedEric NOULARD CPackDeb Component support 
child of 0010736closedEric NOULARD Enable CPack generators to produce more than one package 

-  Notes
Douglas Gregor (developer)
2008-09-11 10:30

The chance of me having time to implement this feature is pretty small. Anyone should feel free to go ahead and implement this if they feel so motivated :)
João Henrique F. Freitas (reporter)
2009-07-01 08:45


I need it for DEB and RPM packages. If you tell me some guidelines I will start it now and you can review.

Waiting, thanks.
Eric NOULARD (developer)
2009-07-01 11:17

I may give you some help for RPM.
First of all you may have a look at CPackRPM specific documentation: [^]

The main design idea of CPackRPM is to avoid coding in C++ when possible.
Thus the content of CMake/Source/CPack/cmCPackRPMGenerator.[cxx|h] is minimal.
The features are implemented mainly in CMake/Modules/CPackRPM.cmake.
This way CPackRPM is easily patchable/upgradable without recompilation.
Most of the time
you just have to put your own CPackRPM.cmake into the CMake module path
in order to patch it. The component feature however needs some C++ part

However you should update cmCPackRPMGenerator.* in order to
indicate that the generator supports components, i.e. redefine
virtual method
virtual bool SupportsComponentInstallation() const;

like it is done in the NSIS generator (see cmCPackNSISGenerator.*).

Once you've done that (easy part) I would go back to CPackRPM.cmake
in order to make it aware of COMPONENT case. For example the C++
part may setup some CPACK_RPM_COMPONENTS with appropriate value
and then use


in CPackRPM.cmake in order to make specific action in component case.

In the current (non-component) case CPackRPM build a single RPM
with all what is found in
i.e. the buildroot.
This is done by writing a *single* RPM spec file and calling
rpmbuild with appropriate arguments.

What you may try to do is the same thing but doing a loop
over the requested components list.

CPack should install the component specific file in

You may then build one spec file by component.
And call rpmbuild for each component.

A may be expected feature would be to automatically add rpm
dependencies for those components rpm.

This is the big picture on how I would do it if I had time to it.
This is a proposition, not a "must go this way".
Feel free to propose another way to go.

I'm not an official CMake developer
(as a consequence I have not commiit access to CMake CVS tree)
I did just contribute the CPackRPM generator.

I'll try to help you as much as I can.
May be we can begin to share the componentized CMake project test case
you want, may be you can write one and put the corresponding zip
as an attachment in the tracker.

Or may be we can use the one given here: [^]
Eric NOULARD (developer)
2009-07-13 07:38

Hi joaohf,

Did you begin some work on this?
I would be ready to test :-)
João Henrique F. Freitas (reporter)
2009-07-14 19:52

Hi Eric.

Not yet. I am reading the code and make some notes. I will start on next week.

Eric NOULARD (developer)
2009-08-12 03:28

Hi Joahf,

Did find the time to work on COMPONENT support for RPM?
João Henrique F. Freitas (reporter)
2009-09-19 13:01


I am working it.

No problems. I am modifying the CPackRPM.cpack generator. The c++ classes is Ok.
João Henrique F. Freitas (reporter)
2009-09-19 20:34


Eric see the three files attached. It need to do a big refactor but works. The dependences between components is not working yet.

I don't know how to solve it:

joaohf@joaohf-laptop:~/tmp/ComponentExampleStart/build$ make package
CPack: Compress package
CPack: Finalize package
CPack Error: Problem copying the package: /home/joaohf/tmp/ComponentExampleStart/build/_CPack_Packages/Linux/RPM/MyLib-1.0.0-Linux.rpm to /home/joaohf/tmp/ComponentExampleStart/build/MyLib-1.0.0-Linux.rpm
CPack Error: Error when generating package: MyLib
make: ** [package] Erro 1

joaohf@joaohf-laptop:~/tmp/ComponentExampleStart/build$ ls _CPack_Packages/Linux/RPM


Three rpm package was created but CPACK can't copy they.

Eric NOULARD (developer)
2009-09-20 05:43


I'll try your patch soon.
I'll try to see why there is a copy trouble.
Eric NOULARD (developer)
2009-09-20 06:51


I know why CPack can't copy the packages...
In fact it seems that Component Install was designed with the idea
in mind that componentized installer will only produce a single file...

If you look at the NSIS and PackageMaker generators, they currently
work that way. They understand components but they still produce
a single installer.

This is not the case of what I thought for DEB, RPM etc...
In fact I think that the idea of a single file installer is somehow
Imagine I want to add COMPONENT support for TGZ, ZIP etc... I would
find it better to produce several files than a single one containing
the whole component.

I'm afraid you'll have to propose a patch for the generic cmCPackGenerator.
The "cmCPackGenerator::SupportsComponentInstallation" API is not enough
the specific generator should be able to tell its mother class
that it will produce as many "installer files" as components.

The trouble with this is that currently the base class
cmCPackGenerator decides the name of the file for the specific generator.
I think this is wrong too.

The base class should provides the list of files to package
and the temp directory they reside in **BUT** it should
reads back from the call the list of file the specific generator
has produced.

This way the base class may generically copy the generated files
(may be several) appropriately.

That's more work than expected. I did not see that component install
did assume the installer should produce a single file...

This design issue should be discussed with CMake developper (not me)
in order to choose the appropriate new design they will be wanting
to promote/accept.
João Henrique F. Freitas (reporter)
2009-09-20 15:57


Any developer is reading it?

Eric, you know a CMake developer? I am not very familiarized with CMake code, so is difficult to propose some other idea.

I agree with you.
Eric NOULARD (developer)
2009-09-21 02:18

I would try to call for help/advice on the CMake ML
pointing to this particular bug.
Some CMake developer may come and give their opinion.
I send the first message and let you follow-up on the list.

Concerning the knowledge of the CMake code, I'm not that familiar
too however the code is usually well written such that after
some time reading it you get good ideas of what to do.
Bruno Hecht (reporter)
2009-09-21 08:31


I need to create sub-packages DEB with cpack, but, always generate an only pack:


# package generation

CPack: Create package using DEB
CPack: Install projects
CPack: - Run preinstall target for: MyProject
CPack: - Install project: Project
CPack: Compress package
CPack: Finalize package
CPack: Package /home_local/workcopy/branches/build/MyProject.deb generated.

How I make sub-packages? My knowledge in cmake and cpack is starting now.

Eric NOULARD (developer)
2009-09-21 14:30

Hi "hecht",

The purpose of the bug is precisely to try to add COMPONENT support
for RPM and DEB CPack generator, in order to create one "sub-package"

The current effort began with RPM which now hits a CPack design problem
(not that hard but still needs more work).
Once this problem has been solved for RPM it should be easy to port
the RPM effort on DEB (and may be other like TGZ, ZIP and the like).
João Henrique F. Freitas (reporter)
2009-09-21 20:56

Hi "hecht".

Welcome to the work. I think you need to tell cmCPackDebGenerator.cxx|h about the SupportsComponentInstallation virtual method. As Eric said.

In CPackDeb.cmake is necessary some work. But I believe the hard wokr is inside cmCPackDebGenerator::CompressFiles. We need to tell how the components will be compressed.

CPackRPM is more easy because all the code is inside CPackRPM.cmake.
Eric NOULARD (developer)
2009-11-15 14:17

I have open a related bug: [^]
Eric NOULARD (developer)
2010-11-13 13:58

Back at work.
I've just pushed the first set of change to next.
2c84d16 CPackRPM add basic component support to CPackRPM
Eric NOULARD (developer)
2011-01-05 02:56

This bug may be closed because the basic component support is OK.
I'm opening child/related bug report in order to handle follow-up
in future CMake/CPack release, see: [^] [^]

- Issue History
Date Modified Username Field Change
2008-09-10 08:46 Eric NOULARD New Issue
2008-09-11 10:19 Bill Hoffman Status new => assigned
2008-09-11 10:19 Bill Hoffman Assigned To => Douglas Gregor
2008-09-11 10:30 Douglas Gregor Note Added: 0013417
2009-07-01 08:45 João Henrique F. Freitas Note Added: 0016793
2009-07-01 11:17 Eric NOULARD Note Added: 0016795
2009-07-13 07:38 Eric NOULARD Note Added: 0016851
2009-07-14 19:52 João Henrique F. Freitas Note Added: 0016871
2009-08-12 03:28 Eric NOULARD Note Added: 0017100
2009-09-19 13:01 João Henrique F. Freitas Note Added: 0017644
2009-09-19 20:18 João Henrique F. Freitas File Added:
2009-09-19 20:19 João Henrique F. Freitas File Added: CPackRPM.cmake
2009-09-19 20:28 João Henrique F. Freitas File Added: cmake.diff
2009-09-19 20:34 João Henrique F. Freitas Note Added: 0017652
2009-09-20 05:43 Eric NOULARD Note Added: 0017658
2009-09-20 06:51 Eric NOULARD Note Added: 0017659
2009-09-20 15:57 João Henrique F. Freitas Note Added: 0017662
2009-09-21 02:18 Eric NOULARD Note Added: 0017664
2009-09-21 08:31 Bruno Hecht Note Added: 0017667
2009-09-21 14:30 Eric NOULARD Note Added: 0017681
2009-09-21 20:56 João Henrique F. Freitas Note Added: 0017686
2009-11-15 14:17 Eric NOULARD Note Added: 0018416
2009-11-22 13:33 Eric NOULARD Assigned To Douglas Gregor => Eric NOULARD
2010-04-22 18:04 Eric NOULARD Relationship added related to 0009900
2010-05-20 13:36 Eric NOULARD Relationship added child of 0010736
2010-11-10 13:07 David Cole Target Version => CMake 2.8.4
2010-11-13 13:58 Eric NOULARD Note Added: 0023245
2011-01-05 02:53 Eric NOULARD Relationship added parent of 0011656
2011-01-05 02:56 Eric NOULARD Note Added: 0024409
2011-01-05 02:56 Eric NOULARD Status assigned => closed
2011-01-05 02:57 Eric NOULARD Resolution open => fixed
2011-01-05 02:57 Eric NOULARD Fixed in Version => CMake 2.8.4
2011-01-05 03:00 Eric NOULARD Relationship added related to 0011655

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker