[cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

Domen Vrankar domen.vrankar at gmail.com
Mon Apr 20 15:27:00 EDT 2015


>> 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


More information about the cmake-developers mailing list