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

[Raffi Enficiaud]

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