2010/8/2 David Cole <[email protected]>: > On Sun, Aug 1, 2010 at 6:17 PM, Eric Noulard <[email protected]> wrote: >> >> 2010/8/1 Dennis Schridde <[email protected]>: >> > 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 _______________________________________________ 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
