[CMake] CPack integration

[Eric Noulard]

2010/8/2 David Cole <david.cole at kitware.com>:
> On Sun, Aug 1, 2010 at 6:17 PM, Eric Noulard <eric.noulard at gmail.com> wrote:
>>
>> 2010/8/1 Dennis Schridde <devurandom at gmx.net>:
>> > Hello!
>> >
>> > I just started experimenting with CPack. According to the docs and
>> > code it is to be used like this:
>> >> set(CPACK_... ...)
>> >>
>> > include(CPack)
>> >
>> > This, however, does not allow making use of the defaults
>> > present in CPack.cmake. (Most notably CPACK_SOURCE_IGNORE_FILES.)
>> > I had to
>> > copy the default value of that variable out of CPack.cmake into my own
>> > CMakeLists.txt, which does not seem very clean.
>> >
>> > Can you add a way of
>> > configuring CPack that allows appending or modifying default values?
>> > What
>> > comes to my mind is a semantic like this:
>> >> include(CPack)
>> >> set(CPACK_...
>> > "${CPACK_...} ...")
>> >> cpack_config()
>>
>> I think this is an interesting idea.
>> May be it's worth a feature request on the tracker:
>> http://public.kitware.com/Bug/my_view_page.php
>>
>> This would even be better with a patch proposal :-)
>>
>> My personal point of view with your idea is that
>> since we most most probably want to maintain backward compatibility
>> it would even be better if we can do
>>
>> 1 - set(CPACK_...
>> 2 - include(CPack)
>> 3 - set(CPACK_...)
>> 4 - cpack_update_config() or cpack_reconfig()
>>
>> that way 1, 3 and 4 are optional just as today.
>> 3 and 4 would bring what you suggest.
>
>
> You can already do this today with:
> 1 - set(CPACK_...
> 2 - include(CPack)
> 3 - set(CPACK_...)
> 4 - include(CPack)
> Simply including CPack a second time will configure the files according to
> the new values set in step 3. No need for a bug tracker entry, no need to do
> any update or re-config. Simply including CPack a second time will call
> configure_file for the two files of interest: CPackConfig.cmake and
> CPackSourceConfig.cmake...

The second CPack inclusion is not always working as expected
http://public.kitware.com/Bug/view.php?id=10751

most probably because of the "cpack_set_if_not_set" usage inside CPack.cmake

like I said before
set(CPACK_...
include(CPack)

"looks like a function call" but it has several unexpected side effect
because it is not a function call.

To be honest I'm not saying it's not useful as-it-is, it is **not always**
obvious to guess which CPACK_xxx
variables will be taken into account and which won't because of the first
set(CPACK_....)


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