Le 28/04/15 12:23, Domen Vrankar a écrit :
Hi,
Sorry for not replying sooner.
Please find attached a patch for the reworked documentation. I tried to make
the doc more consistent with the CPackRPM (doc right after the variable
declaration and options afterwards).
I also put links for the variables and changed the formatting a bit.
Thanks for the patches. You are doing a great work but please start
splitting patches into subpatches... Each patch you provide is a
combination of fixing one thing and adding a bunch of new things to it
as well. Until one patch is added to master that patch is not finished
and should not be built upon with new patches that are remotely
related at best.
If you intend to provide the patches like that then rework the patches
yourself and resubmit all of them each time until they are applied.
There are a couple of things though:
- the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code
I'll take a look after we finish with current patches...
- right now, the CPACK_COMPONENT_<COMP>_DESCRIPTION is used as an equivalent
to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM
conventions, those would be called CPACK_DEBIAN_<COMP>_PACKAGE_DESCRIPTION,
which I find also better. However, in that case, should it default to
CPACK_COMPONENT_<COMP>_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION?
In fact CPACK_COMPONENT_<COMP>_DESCRIPTION and
CPACK_DEBIAN_<COMP>_PACKAGE_DESCRIPTION would have the same purpose and I
think that it will not be obvious for the user to cope with all those
variables.
They would not have the same purpose - one is for setting value for
all package generators at once while the other is for debian specific
content.
I am not a fan of generator specific overrides so I haven't bugged you
with that entire hierarchy because it can be added later and because
you volunteered for completely different functionality in the first
place.
On the other hand that is the preferred way of Brad and Eric so I
intended to add the overrides later on.
Regards,
Domen
Hi,
I did not get exactly what you wanted at the end for the component based
descriptions, so I left the functionality as is.
So for now, I am addressing the issue "CPackDEB: support for description
per component".
Please find attached the patch concerning the description per component,
with the associated documentation, based on
75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06.
I reworked the tests in the same spirit as you did for merging the
previous patch to master. I will then rebase my other branches on the
changes you might make. For that purpose, please send me a revision on
which I can rebase my current work.
I will not move until you validate this patch and merge it to trunk,
because otherwise I would base work on moving bases. Please note that
this is only one of the features I need. On my side, I need two
additional functionalities (shlibdeps + dependency per component).
Best,
Raffi
--
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
