One other idea came to mind... Allow arbitrary paths for different prefixes and a script to generate prefixes from paths in GNUInstallDirs. That would be a more general solution.
I could also remove the use of GNUInstallDirs paths all together but I like the idea of having packaging relocation paths set automatically by defining install paths since that guarantees the consistency of the structure installed by cmake and from rpm... 2015-01-16 23:06 GMT+01:00 Domen Vrankar <[email protected]>: > Resending as I accidentally dropped the developers mailing list... > > 2015-01-16 22:38 GMT+01:00 Brad King <[email protected]>: >> On 01/16/2015 08:42 AM, Brad King wrote: >>> Go ahead and merge to 'next' for testing and follow up with any >>> dashboard trouble. I'll still be able to review it there. >> >> AFAICT the change to GNUInstallDirs is just to help projects use >> the new feature, and not actually part of the new feature itself. >> The feature itself just happens to use the same set of <dir> values. > > Yes I added variables to GNUInstallDirs as a convenience method. Users > can still choose to set values without the use of GNUInstallDirs > module. > >> It feels a bit strange to have CPACK_ variables set by GNUInstallDirs, >> and to require CPACK_PACKAGING_INSTALL_PREFIX to be set before that >> module is included. >> >> Perhaps instead CPackRPM can provide an option to compute a default >> for CPACK_PACKAGING_INSTALL_FULL_<dir> based on the GNUInstallDirs >> values. This way GNUInstallDirs does not have to change at all, >> and users can choose to include GNUInstallDirs and still set their >> own CPACK_PACKAGING_INSTALL_FULL_<dir> values separately. > > I tried to do that first but the problem is that only CPACK_* > variables are propagated to CPackRPM script and I thought that > redefining the variables with new names in GNUInstallDirs is better > than creating a new module just for that. > > I could write a new module for converting CMAKE_INSTALL* variables to > CPACK_PACKAGING_INSTALL* variables and then generate > CPACK_PACKAGING_INSTALL_FULL_< > dir> inside CPackRPM. > > Alternative that comes to mind is that I just remove the convenience > method of setting variables through GNUInstallDirs. > > I'm opened to suggestions. > >>> + set(TMP_RPM_PREFIXES ${TMP_RPM_PREFIXES} PARENT_SCOPE) >> >> Typically I quote the second argument in this case. It is not >> strictly necessary but looks cleaner IMO. > > I agree. > >> Please look at adding test cases, perhaps in Tests/RunCMake, >> to check the warning message about non-relocatable paths. > > Haven't tried to write negative tests or parsing of command line > during test execution. Are there any good examples of such tests? > >> Thanks, >> -Brad >> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
