[CMake] find_package config and install

[Lars]

Alan,


Thank you very much for the response.


Our 'foo' package does not use CMake. That means there is no build-system to produce the foo-config.cmake file, the file is manually created.  The file does allow different projects to import the target from 'foo' package that has been installed. However, we need to include the library and config file in CPack installer and who is responsible for that task?


We are using Qt5 config mode to import targets like you describe in development context and it works. However, to setup packaging system (CPack) we need to perform the Install(..) command so
that the necessary Qt5 targets are included in the installer (MSI and RPM). We cannot require the customer to install a 2GB Qt5 installer for a few libraries. In that context it is unclear who\when\how should perform the installation.


kind regards, Lars


________________________________
Fra: Alan W. Irwin <Alan.W.Irwin1234 at gmail.com>
Sendt: tirsdag 22. januar 2019 09.29
Til: Lars
Kopi: cmake at cmake.org
Emne: Re: [CMake] find_package config and install

On 2019-01-21 11:09-0000 Lars wrote:

> Hello,
>
> We are creating a foo-config.cmake file for a package. The 'foo' package contain a dynamic library that provides two interfaces and a number of configuration files. There is a mapping between an interface and required configuration files. What is the recommended approach for installing targets and necessary configuration files in this context? Should this be performed by foo-config.cmake or system that performed find_package? If foo-config.cmake should perform the install, how should it be informed of which interface is required? Can the "components" tag be used for this task?
>
> Qt 5.11 support config mode but does not perform any install. Does anyone know why?
>
> We are using CMake 3.13.2
>

Hi Lars:

Here is an overview of packaging which I believe will
be useful to you.

foo-config.cmake does no installation itself.  Instead,
the build system for project "foo" installs that file to
help keep track of all the installed targets for foo that
get exported by foo.  That file (and the many files it includes)
allows different projects to import foo targets with ease
from a foo package that has already been installed.

So, for example, Qt5 config mode allows your project to import Qt5
targets that have been exported by that project, but in order to
access that functionality, Qt5 has to already be installed by some
means completely independent of CMake.

Some references that explain all this (and a lot more) are
<https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html>,
the install(EXPORT...) variant of the install commmand documented in
<https://cmake.org/cmake/help/latest/command/install.html>,
and <https://cmake.org/cmake/help/latest/command/export.html>.

In sum, cmake makes it trivially easy to import targets (e.g., from an
already installed Qt5 package).  It is substantially more work to
export targets from your own "foo" project using the foo-config.cmake
approach because there are a fair number of details you have to keep
track of to provide a useful result that other projects can import
successfully.  But exporting is pretty straightforward once you
have read the above documentation, and it sure makes life convenient
for other projects which wish to import targets from an already
installed foo package.

Alan
__________________________
Alan W. Irwin

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
__________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190122/586c677b/attachment-0001.html>