[CMake] What is the proper way to export targets that will be split into separate binary packages?

[Alan W. Irwin]

On 2015-04-28 11:57+0200 Nils Gladitz wrote:

> On 04/28/2015 11:43 AM, Alan W. Irwin wrote:
>> @Nils: the origin of the code right below "If COMPONENTS..." is not
>> clear.  Is that code that should be supplied by a package creator or
>> code that
>> should be implemented by every find_package user?  And if it should be
>> supplied by a package creator, does the install(EXPORT...) signature
>> generate that code automatically, does one of the helper functions
>> that are available generate that code, or do I (as package creator)
>> have to supply that code some other way?
>
> The package configuration file is normally handwritten (or handgenerated) by 
> the package creator. I assume you already have one? e.g. plplotConfig.cmake.

Yes, I did implement such a file a while back to bring the previous
crude export stuff (implemented years ago before the idea of cmake
packages were even thought of) into compliance with the idea of cmake
packages.  However, now that you have reminded me of that file, it
turns out it is only slightly more than a placeholder.  So clearly
some work is required to fully modernize this part of the PLplot build
system.

>
>
>>> http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages
>>> 
>> 
>> @Alex: Sorry I missed your reply until now.
>> 
>> @Alex or Nils:
>> 
>> The problem with the URL provided by Nils is only one library is used
>> in the example so I don't understand exactly what you guys are
>> suggesting for the multiple library/component case.
>> 
>> For example, are you recommending
>> 
>> install(TARGETS plplot1 EXPORT export_plplot ...)
>> [...]
>> install(TARGETS plplotN EXPORT export_plplot ...)
>> 
>> for N installed libraries followed by
>> 
>> install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot)
>> 
>> ?  That is the current pattern I am using with one overall export name
>> called "export_plplot".   Or would you recommend this different pattern
>> 
>> install(TARGETS plplot1 EXPORT export_plplot1 ...)
>> install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot)
>> [...]
>> install(TARGETS plplotN EXPORT export_plplotN ...)
>> install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot)
>> 
>> (i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures
>> with each pair having a unique export name)?
>
> Yes, unique/distinct export names and export files.
>
> That way the target export files can go into the respective distribution 
> package that they represent.
>
> The "umbrella" package configuration file would be installed by your "core" 
> package and would then be able to pick up the currently available target 
> export files.

Thanks for that clarification.

You referred in a later post to the granularity required. To give you
some idea of the scope of the problem, there are currently ~30 PLplot
targets which are EXPORTed. I obviously do not want to set up 30
different package components to correspond to those individual targets
since that implies maintenance issues (for users to keep track of all
those possible components).  On the other hand, the current
granularity requirements of the Linux packagers vary quite a lot
between distros (e.g., Debian packagers tend to split PLplot binary
packages differently than Fedora packagers) probably because upstream
PLplot has not given them any splitting guidance until now.  So I will
have to think carefully about what component granularity we should
supply.

Anyhow, you have given me lots of food for thought here, and I
appreciate that!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________