2010/8/23 Clinton Stimpson <clin...@elemtech.com>:
> On 08/22/2010 10:47 AM, Eric Noulard wrote:
>>
>> 2010/8/22 Eric Noulard<eric.noul...@gmail.com>:
>>
>>>
>>> 2010/8/21 Clinton Stimpson<clin...@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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
