Should configuration package files define module package variables?

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

Should configuration package files define module package variables?

Robert Dailey-2
So I've been studying the find_package[1] and "creating packages"[2]
documentation, as well as the CMakePackageConfigHelpers[3] page.

Based on the current offerings of configuration packages, I do not
understand the need for the relocatable config.cmake file when all it
really contains is:

include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)

However, what I'm wondering is even though the import targets should
contain all information about include directories, libraries, etc,
should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
variables? Example of what foo-config.cmake would be like:

include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
set( Foo_INCLUDE_DIRS "... path here...." )
set( Foo_LIBRARIES "List of libraries here..." )


Is this necessary? Honestly the learning curve for creating packages
for find_package is very steep. I did not see any general advice on
this kind of stuff. It seems like Module packages are being deprecated
in favor of Config packages, because it puts the responsibility of
maintaining find package logic on the upstream maintainer (config
package) instead of on CMake (module packages it ships with).

Thanks in advance for any help.
--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Should configuration package files define module package variables?

Robert Dailey-2
Doh, forgot the links I intended to reference in my original email:

[1]: https://cmake.org/cmake/help/v3.6/command/find_package.html
[2]: https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-packages
[3]: https://cmake.org/cmake/help/v3.6/module/CMakePackageConfigHelpers.html

On Fri, Aug 25, 2017 at 11:21 AM, Robert Dailey
<[hidden email]> wrote:

> So I've been studying the find_package[1] and "creating packages"[2]
> documentation, as well as the CMakePackageConfigHelpers[3] page.
>
> Based on the current offerings of configuration packages, I do not
> understand the need for the relocatable config.cmake file when all it
> really contains is:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
>
> However, what I'm wondering is even though the import targets should
> contain all information about include directories, libraries, etc,
> should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
> variables? Example of what foo-config.cmake would be like:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
> set( Foo_INCLUDE_DIRS "... path here...." )
> set( Foo_LIBRARIES "List of libraries here..." )
>
>
> Is this necessary? Honestly the learning curve for creating packages
> for find_package is very steep. I did not see any general advice on
> this kind of stuff. It seems like Module packages are being deprecated
> in favor of Config packages, because it puts the responsibility of
> maintaining find package logic on the upstream maintainer (config
> package) instead of on CMake (module packages it ships with).
>
> Thanks in advance for any help.
--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Should configuration package files define module package variables?

Johannes Zarl-Zierl
In reply to this post by Robert Dailey-2
Hi,


On Freitag, 25. August 2017 11:21:50 CEST Robert Dailey wrote:
> However, what I'm wondering is even though the import targets should
> contain all information about include directories, libraries, etc,
> should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
> variables?

This depends very much on the target audience of your config.cmake file. My
personal opinion is that you can skip those variables entirely for new
projects. (Somebody please correct me if I'm wrong!)

> It seems like Module packages are being deprecated
> in favor of Config packages, because it puts the responsibility of
> maintaining find package logic on the upstream maintainer (config
> package) instead of on CMake (module packages it ships with).

Yes. This has been the case since cmake 2.8 or so. A general rule of thumb for
module vs. config:
If you are the upstream: create a config  package.
If the upstream is somebody else, but uses cmake: submit a patch and get them
to provide a config package.
If the upstream does not use cmake: they can still provide a config package.
If all else fails: add a module to your project to find the upstream library.

Cheers,
  Johannes

P.S.: And yes: creating a config package has a steep learning curve. Link [2]
has all the information you need, but it is hardly a nice tutorial...
--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Should configuration package files define module package variables?

CMake mailing list
In reply to this post by Robert Dailey-2

> On Aug 25, 2017, at 11:21 AM, Robert Dailey <[hidden email]> wrote:
>
> So I've been studying the find_package[1] and "creating packages"[2]
> documentation, as well as the CMakePackageConfigHelpers[3] page.
>
> Based on the current offerings of configuration packages, I do not
> understand the need for the relocatable config.cmake file when all it
> really contains is:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)

In general, if the library does not have any dependencies, you can just export the targets directly to the config.cmake file:

install(TARGETS foo EXPORT foo-config)
install(EXPORT foo-config DESTINATION lib/cmake/foo)

However, if the library has dependencies, you will need to iterate over them in the config.cmake file. That is if `foo` uses zlib, like this:

find_package(ZLIB)
target_link_libraries(foo ZLIB::ZLIB)

Then the foo-config.cmake needs to do this(assuming the export targets are written to foo-targets):

include(CMakeFindDependencyMacro)
find_dependency(ZLIB)
include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake”)

The reason for this is that the imported foo target will link against ZLIB::ZLIB, but it will not define it. Actually, the generated foo-targets.cmake will create an error if ZLIB::ZLIB doesn’t exists, which is why `find_dependency(ZLIB)`(which is really just `find_package` underneath) needs to be called before including the foo-targets.cmake.

Hopefully that makes sense.

>
> However, what I'm wondering is even though the import targets should
> contain all information about include directories, libraries, etc,
> should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
> variables? Example of what foo-config.cmake would be like:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
> set( Foo_INCLUDE_DIRS "... path here...." )
> set( Foo_LIBRARIES "List of libraries here...” )

In general, defining relocatable variables like `Foo_INCLUDE_DIRS` was more common in with cmake 2.8. With modern cmake using just the imported targets is much better then dealing with all those variables and trying to make them relocatable.


--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Should configuration package files define module package variables?

Robert Dailey-2
On Sat, Sep 2, 2017 at 3:08 AM, P F <[hidden email]> wrote:

> In general, if the library does not have any dependencies, you can just export the targets directly to the config.cmake file:
>
> install(TARGETS foo EXPORT foo-config)
> install(EXPORT foo-config DESTINATION lib/cmake/foo)
>
> However, if the library has dependencies, you will need to iterate over them in the config.cmake file. That is if `foo` uses zlib, like this:
>
> find_package(ZLIB)
> target_link_libraries(foo ZLIB::ZLIB)
>
> Then the foo-config.cmake needs to do this(assuming the export targets are written to foo-targets):
>
> include(CMakeFindDependencyMacro)
> find_dependency(ZLIB)
> include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake”)
>
> The reason for this is that the imported foo target will link against ZLIB::ZLIB, but it will not define it. Actually, the generated foo-targets.cmake will create an error if ZLIB::ZLIB doesn’t exists, which is why `find_dependency(ZLIB)`(which is really just `find_package` underneath) needs to be called before including the foo-targets.cmake.

When you throw components in the mix, where you have 1 targets.cmake
exported per component, each may have its own find_dependency()
requirements. It would be nice if that was self-contained in the
targets.cmake script itself, but there's no examples I could find on
how to manage per-component find dependencies like this, especially if
those components are put into `OPTIONAL_COMPONENTS`.

Thanks for the information, it is very helpful!
--

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:
http://public.kitware.com/mailman/listinfo/cmake