Le 20/04/15 19:19, Domen Vrankar a écrit :
Hi,
[...]
- CPackRPM: all the RPM creation is driven by the CPackRPM.cmake itself
- CPackDEB: part of package configuration is sent from the .cmake back to
the cmCPackDebGenerator.cxx, and some internal functions in C++ are creating
the package definition.
Sorry about that... I completely forgot about that difference.
no worries!
The workflow is not the same, so if I scope all the variables in a function
in the .cmake file, I have no way to get these variables back in the .cxx
file. For the RPM package, this is fine since at the end of the
CPackRPM.cmake call, the package is created.
My guess is that I do not have the choice: I have to do some set/unset to
avoid inter-component troubleshooting.
Any suggestion more than welcome.
The thing is that inside CPack you can only access variables from
project CMakeLists.txt that are prefixed by CPACK_ so CPackDEB can
even see CPACK_RPM* variable settings.
Ok
Variables also can't be set across different CPack generators e.g. if
I set a variable inside CPackRPM generator and then run both RPM and
DEB generator at the same time the value won't be present in CPackDEB
generator.
Ok
On the other hand variables that are set in CPackDEB.cmake for one
component are later visible in the other - they don't get reread from
CMakeLists.txt for every pass. So setting variables inside
CPackDEB.cmake is a bit dangerous.
Ok. I do not understand that much the value of this feature, if this is
intended. For instance, if I would like to make something available to
all components (eg. some transformation of the name for instance), I
would do this implementation in the .cxx file by running the loop on all
components and populating an internal variable of the .cxx file. I would
avoid anything that depends on the sequence of the components seen by
the CPackDeb.cmake.
For instance, if I have to implement the inter-component dependency, I
though a possible implementation would be
- loop through all the components and get back eg. the component
debianized name, without generating the package (kind of dry-run)
- put all those names into a map that is available to the generator
- loop through all the components, with this map available, and generate
the component package.
On the other hand, the risks might be limited if, by /convention/, we
say that all _cpack_deb_local_*** variables are reserved for local use
only, initialized at the beginning of the CPackDeb.cmake (or before).
I do not know that much the interface between the C++ and .cmake (for
example, I do not know if this is possible to get all _cpack_deb_local_*
variables, or call only one function of the .cmake instead).
For that reason every CPackDEB variable that is used in
cmCPackDebGenerator::createDeb() will have to be renamed for e.g. from
CPACK_DEBIAN_PACKAGE_NAME to something like _CPACK_DEBIAN_PACKAGE_NAME
and in CPackDEB.cmake those variables would have to be set(...
PARENT_SCOPE) from let's say cpack_deb_generate_package() function for
every pass. That way you contain variable setting and prevent future
accidental overwrites.
I'll write a patch for that today and push it to next. I'll also add
link here so that you'll be able to use it before it gets to master.
Sounds like a bunch of conflicts on my side :)
Go ahead.
Best,
Raffi
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
