[cmake-developers] [CPack] [CPackRPM] mantis ticket 13176 CPackRPM support for per-component summary and description

[Domen Vrankar]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20141021/e1b595af/attachment-0002.html>