find_package config and install

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

find_package config and install

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

kind regards, Lars


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: find_package config and install

Alan W. Irwin-2
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
__________________________
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: find_package config and install

Lars 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 <[hidden email]>
Sendt: tirsdag 22. januar 2019 09.29
Til: Lars
Kopi: [hidden email]
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
__________________________

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: find_package config and install

Alan W. Irwin-2
Hi Lars:

On 2019-01-22 12:05-0000 Lars wrote:

> Alan,
>
>
> Thank you very much for the response.

You are welcome.

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

As you are probably already aware, the Qt5 software produces their "*-config.cmake" in a non-CMake way.
And it appears you are attempting to follow that method for your own
"foo" package case.  I applaud that attempt since that end result
should make life much easier for users of your foo package that do use
CMake.  However, now I hear you are using CPack for foo as well.  So
maybe it is time to bite the bullet and move foo to a cmake build
(which should make your life much simpler for creating both a working
"foo-config.cmake" file and a working CPack configuration.)

I specifically used the term "bite the bullet" because changing build
systems for any large software project with many different executables
and libraries is obviously not a trivial task.  But I assure you the
end goal of having a complete CMake-based build, test, and CPack
system is worth the pain of the transition.  But I would also advise
you it is possible to get from your present state to that goal in
small manageable steps that are not painful at all because partially
implemented CMake-based build systems normally happily coexist with
other build systems.

To take an example of such a soft (and completely unplanned)
transition to CMake (from more than a decade ago now) in the PLplot
case we had a mature autotools-based build system that was mostly good
enough "except for a few nagging problems...."  So out of curiosity
more than anything else I started a hobby project of implementing the
build of just one of our smaller libraries with CMake.  And that
proved to be trivial (it only took a half an hour or so to learn what
I needed about CMake starting from zero knowledge), and the resulting
library built much faster.  Following up on that initial promising
result I quickly (with some substantial help from other PLplot
developers at the time who were interested in learning about CMake)
extended that hobby build system to more and more of our libraries and
executables.  Until within a month or so of me starting this "hobby"
this self-organized group of
developers for our CMake-based build system was producing the same
libraries, shared-objects, and executables as our "standard"
autotools-based build system.  But that configuration was much easier
to understand than for our standard build system, and both the
configuration and build was much faster than for the autotools case.

As a result we "got serious" and for the next month or so extended the
work to support both PLplot testing and the installed version of
PLplot to essentially complete the project.  For a year after
that we maintained both the CMake-based and autotools-based build
systems, but interest in the latter dropped so fast that at
the end of that year we completely removed all traces of
our autotools-based build system from our source tree, and we
never regretted that decision.

Note, this transition to a CMake-based build system would likely not
have ever happened if we attempted to plan it from the start.
Instead, treating it like a learning hobby motivated me and the rest
of our development group a lot, and we achieved a very fast and
non-painful transition as a result.

Of course, you may reply that the "foo" case is completely different
and you are completely happy with your present build system for that
software.  If so, that is fine.  However, if you have some nagging
doubts about that build system (for example, some inconveniences when
implementing the "foo-config.cmake" file, configuring CPack, or
ultimately (if you are interested in testing "foo" configuring CTest)
then perhaps it is time for you to start a possible soft transition to
a CMake-based build system for "foo" as a hobby style of project
without the type of "planning" that often kills such potentially
useful projects dead.

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

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: find_package config and install

Lars Lars
Alan,

Appreciate you taking the time to help.

It is unfortunately not an option to move 'foo' package to CMake at this time.

To summarize, we want to perform find_package in config mode to a none-CMake package that contain a target and some config files. Our current solution is to manually create the foo-config.cmake file that creates an imported target and sets properties on target. The 'foo' package must work with CPack in order to include the necessary files in MSI and RPM. As an experiment we added two install(..) commands to the foo-config.cmake file and this does include both 'foo' target and configuration files in the installers. However we are not sure if this is good modern CMake solution. This solution means that find_package(..) will automatically install files to the build tree which is slightly more functionality than the command name indicates.

Any comments are welcome 😊

kind regards, Lars


Fra: Alan W. Irwin <[hidden email]>
Sendt: onsdag 23. januar 2019 04.14
Til: Lars
Kopi: [hidden email]
Emne: Re: Sv: [CMake] find_package config and install
 
Hi Lars:

On 2019-01-22 12:05-0000 Lars wrote:

> Alan,
>
>
> Thank you very much for the response.

You are welcome.

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

As you are probably already aware, the Qt5 software produces their "*-config.cmake" in a non-CMake way.
And it appears you are attempting to follow that method for your own
"foo" package case.  I applaud that attempt since that end result
should make life much easier for users of your foo package that do use
CMake.  However, now I hear you are using CPack for foo as well.  So
maybe it is time to bite the bullet and move foo to a cmake build
(which should make your life much simpler for creating both a working
"foo-config.cmake" file and a working CPack configuration.)

I specifically used the term "bite the bullet" because changing build
systems for any large software project with many different executables
and libraries is obviously not a trivial task.  But I assure you the
end goal of having a complete CMake-based build, test, and CPack
system is worth the pain of the transition.  But I would also advise
you it is possible to get from your present state to that goal in
small manageable steps that are not painful at all because partially
implemented CMake-based build systems normally happily coexist with
other build systems.

To take an example of such a soft (and completely unplanned)
transition to CMake (from more than a decade ago now) in the PLplot
case we had a mature autotools-based build system that was mostly good
enough "except for a few nagging problems...."  So out of curiosity
more than anything else I started a hobby project of implementing the
build of just one of our smaller libraries with CMake.  And that
proved to be trivial (it only took a half an hour or so to learn what
I needed about CMake starting from zero knowledge), and the resulting
library built much faster.  Following up on that initial promising
result I quickly (with some substantial help from other PLplot
developers at the time who were interested in learning about CMake)
extended that hobby build system to more and more of our libraries and
executables.  Until within a month or so of me starting this "hobby"
this self-organized group of
developers for our CMake-based build system was producing the same
libraries, shared-objects, and executables as our "standard"
autotools-based build system.  But that configuration was much easier
to understand than for our standard build system, and both the
configuration and build was much faster than for the autotools case.

As a result we "got serious" and for the next month or so extended the
work to support both PLplot testing and the installed version of
PLplot to essentially complete the project.  For a year after
that we maintained both the CMake-based and autotools-based build
systems, but interest in the latter dropped so fast that at
the end of that year we completely removed all traces of
our autotools-based build system from our source tree, and we
never regretted that decision.

Note, this transition to a CMake-based build system would likely not
have ever happened if we attempted to plan it from the start.
Instead, treating it like a learning hobby motivated me and the rest
of our development group a lot, and we achieved a very fast and
non-painful transition as a result.

Of course, you may reply that the "foo" case is completely different
and you are completely happy with your present build system for that
software.  If so, that is fine.  However, if you have some nagging
doubts about that build system (for example, some inconveniences when
implementing the "foo-config.cmake" file, configuring CPack, or
ultimately (if you are interested in testing "foo" configuring CTest)
then perhaps it is time for you to start a possible soft transition to
a CMake-based build system for "foo" as a hobby style of project
without the type of "planning" that often kills such potentially
useful projects dead.

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
__________________________

--

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:
https://cmake.org/mailman/listinfo/cmake