[CMake] Support for multiple components in cpack (reloaded)

Eric Noulard eric.noulard at gmail.com
Mon Aug 23 11:19:43 EDT 2010


2010/8/23 Clinton Stimpson <clinton at elemtech.com>:
> On 08/22/2010 10:47 AM, Eric Noulard wrote:
>>
>> 2010/8/22 Eric Noulard<eric.noulard at gmail.com>:
>>
>>>
>>> 2010/8/21 Clinton Stimpson<clinton at elemtech.com>:
>>>
>>>>
>>>> I wondered if one would typically use groups if their project contained
>>>> sub projects, and the sub projects had different conventions for the
>>>> component names.
>>>>
>>>
>>> I do not usually work with sub-project and I must admit I don't even know
>>> how CPack behave for project with sub-project(s). I'll try in order to
>>> observe
>>> the current behavior.
>>>
>>
>> Ok now I did some testing regarding CPack and subproject(s).
>>  From my testing and my thinking the conclusion is
>>
>> CPack is not aware **AT ALL** of subprojects :-(
>>
>> It's even worse, since CPack is not meant to be included more than once
>> in the same tree.
>> In fact you already know that because you are the reporter of this:
>> http://public.kitware.com/Bug/view.php?id=10751
>>
>> A related discussion on the ML:
>> http://www.cmake.org/pipermail/cmake/2010-August/038648.html
>>
>> So I would say, unless I misunderstood something,
>> that **currently** you CAN NOT use "subproject" to do any grouping with
>> CPack.
>> If any subproject do include(CPack) while your toplevel project does
>> it as well, you'll get unexpected behavior.
>> The most probable consequence is that is you call "make package" in the
>> toplevel
>> project you'll get a source package instead of a binary package :-)
>>
>> What you CAN ALREADY do is to use your toplevel project to build a package
>> which
>> contains all subprojects. You can even use component in the
>> subproject(s) it will
>> work as expected.
>>
>> If we want to be able to include(CPack) several times, many thing
>> should be changed
>> and we should specify the expected behavior very precisely, I do not
>> think it's as easy
>> as it may seems. Definitely on my workplan now :-(

I may be about to be a little bit disappointing here, but... the previous
phrase contained a typo

"Definitely on my workplan now :-("

 should have been read

"Definitely NOT on my workplan now :-("

thus the not smiling end of the sentence :-(
Sorry about that.

I mean, it would be great to "automagically"  handle subproject
as component, but I think it's not easy.
I'm interested in working on this but NOT NOW :-)

Let's make the current component thing work for ArchiveGenerator,
DEB and RPM and after that we will come back to this
"sub-project as component" topic.

> Yeah, there is that issue, but I'm thinking of something a bit different...
> let me demonstrate with a fictitious example with subprojects:
>
> project A, has sub-projects B, C.
> project B has install() commands with components "Development" and
> "Binaries"
> project C has install() commands with components "Dev" "Runtime"
> And suppose project A has its own naming of components.
>
> now, suppose project A wants to make a component based package, but wants
> B:Development and C:Dev merged together as "Devel," and B:Binaries and
> C:Runtime merged to "Runtime."
>
> Is there anything in cpack to allow for that?  Do we need something like
> that?

Nope nothing I am aware of, CPack cannot "merge" component with different names
you may define a COMPONENT GROUP which contains the differents component.

Like I said before CPack -- is MOSTLY NOT AWARE OF sub-projects --

> I've been getting along fine for a while and I just edit the cmake files of
> my subprojects. I don't know about others though.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org


More information about the CMake mailing list