> > I also wrote a test and noticed two things: > 1) CPackComponentsForAll test is using component names in lower case and > <component> parts in variables in upper case (e.g. COMPONENT headers and > CPACK_COMPONENT_HEADERS_DESCRIPTION). Patch uses > CPACK_RPM_PACKAGE_COMPONENT variable as part of component variable name > e.g. CPACK_RPM_headers_PACKAGE_DESCRIPTION. > Because of this the fallback mechanism doesn't work correctly so is the > correct variable format CPACK_COMPONENT_headers_PACKAGE_SUMMARY, CPACK_ > COMPONENT_HEADERS_PACKAGE_SUMMARY, both or case insensitive? > If case insensitive option is the correct one - how do I implement that? > Since all other RPM component variables use install( ... COMPONENT name) > as part of variable name (so in this case that means lower case) I guess > that RPM versions should stay as they are now ( > CPACK_RPM_headers_PACKAGE_DESCRIPTION for the above example). > > I have fixed a bug in my previous patch - CPACK_COMPONENT_<component>_DESCRIPTION component must be in upper case. CPACK_RPM_<component>* is still treated the same way as with other variables - install( ... COMPONENT name) and name is used as it is without changing it to upper case. I have also added semantic check tests of component description and summary fall backs.
Patches must be applied in order: 0001-CPackRPM-component-based-packaging-description-and-s.patch 0001-add-added-semantic-tests-for-rpm-component-descripti.patch Could someone pleas add the patches to git as I currently don't have commit rights? 2) Package description fallback is currently written as > set(CPACK_RPM_PACKAGE_DESCRIPTION "no package description available") and > this is already in the code - not part of the patch. However if variable > CPACK_PACKAGE_DESCRIPTION_FILE is not set it points by default to > Templates/CPack.GenericDescription.txt and its content is "DESCRIPTION". So > currently the above final fallback is dead code. > Should I delete it or fix the code so that in case of default > CPACK_PACKAGE_DESCRIPTION_FILE value it ignores it and uses "no package > description available" text instead (would break the way it currently works > so I'm guessing that deleting that part of code is the preferred option)? > Can I put this change in the same patch since I am changing the fallback > mechanism in it or should this be a different patch? > If second - can I still attach the patch to the same mantis bug, do I open > a new bug report or just create a patch and post it on the mailing list? > I will create a new bug tracker in mantis for this one and create a patch there. Regards, Domen
-- 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
