>> 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.
I'm not certain either... It was implemented like that when I took over the maintenance of CPackRPM and CPackDEB half a year or so ago. As far as I know with RPM the decision was made that most of the functionality should be in cmake script so that eventually there would be no need for generator specific C++ code - easier to extend/modify functionality for the end users if they need to. Both approaches have their strengths and weaknesses - RPM with most of the logic in cmake script and relying on native rpm tools and configuration. - DEB with relying on C++ code and creating package without the need of deb tools. But for now I'm not trying to change their basic design. > 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). Such agreements have the limitation of being forgotten so I prefer enforcing it in code with a single base function in cmake script :) >> >> 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. Sorry about that :( It's just that I noticed that in the past there were many attempts at preventing accidental leakage of variables in CPackRPM and I don't want to get the same problem in CPackDEB so it's better to prevent it asap. 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
