<div dir="ltr"> <br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I also have a question. Would CPack also need something like CPACK_COMPONENT_<component>_PACKAGE_SUMMARY that could be used by CPACK_RPM_<component>_PACKAGE_SUMMARY as default value?<br></div></div></blockquote><div><br><br></div></span><div>Not sure of that one.<br></div><div>We already have "CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION"<br></div><div>which may be a default value for "CPACK_RPM_<component>_PACKAGE_<div>SUMMARY" if packaging is done "by compoent group" (which is the default):<br><br></div><div>The behavior of the various CPack generator w.r.t. mono- or multi- file/package generation vary,<br></div><div>see:<br><a href="http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior" target="_blank">http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior</a><br><br></div></div></div></div></div></blockquote><div><br></div><div>I did not find CPACK_COMPONENT_GROUP_<component>_DESCRIPTION in documentation but from the examples that I've found googling I think that this would be a better option for CPACK_RPM_<component>_PACKAGE_DESCRIPTION than <span class=""><span>CPACK_RPM_<component>_PACKAGE_SUMMARY. Since the patch supports all the options that I've found in the documentation I guess that there are enough fallback options covered.<br><br></span></span></div><div><span class=""><span>I also wrote a test and noticed two things:<br>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.<br>Because of this the fallback mechanism doesn't work correctly so is the correct variable format CPACK_</span></span><span class=""><span><span class=""><span class=""><span>COMPONENT</span></span></span>_headers_PACKAGE_SUMMARY, CPACK_</span></span><span class=""><span><span class=""><span class=""><span>COMPONENT</span></span></span>_HEADERS_PACKAGE_SUMMARY, both or case insensitive?<br>If case insensitive option is the correct one - how do I implement that?<br>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 (</span></span><span class=""><span><span class=""><span class=""><span>CPACK_RPM_headers_PACKAGE_DESCRIPTION</span></span></span> for the above example).<br><br></span></span></div><div><span class=""><span>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.<br>Should I delete it or fix the code so that in case of default CPACK_PACKAGE_DESCRIPTION_FILE value it ignores it and uses </span></span><span class=""><span class=""><span>"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)?<br>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?<br>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?</span></span></span></div></span></div></div></div>