Proper process for static & shared variants of config packages?

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

Proper process for static & shared variants of config packages?

Robert Dailey-2
Suppose I have a library target and I setup a config package for it
and install target exports for it. What is the process for supporting
installation of the shared library and static library variants (maybe
the same answer applies to debug and release variants too)?

Should you create 1 target and rely on BUILD_SHARED_LIBS, which means
generating two binary directories, building and installing once in
each? Will this overwrite existing target.cmake and config.cmake files
in a negative way?

Or should there be 2 library targets (something like foo_shared and
foo_static) and build & install once?
--

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: Proper process for static & shared variants of config packages?

CMake mailing list

> On Sep 1, 2017, at 10:39 AM, Robert Dailey <[hidden email]> wrote:
>
> Suppose I have a library target and I setup a config package for it
> and install target exports for it. What is the process for supporting
> installation of the shared library and static library variants (maybe
> the same answer applies to debug and release variants too)?
>
> Should you create 1 target and rely on BUILD_SHARED_LIBS, which means
> generating two binary directories, building and installing once in
> each?

This is the best approach as it leaves the decision of building shared or static to the clients.

> Will this overwrite existing target.cmake and config.cmake files
> in a negative way?

You could install each variant of shared and static to separate install directories. For debug and release you can install together, as cmake generates a target-<configuration>.cmake for each configuration. I suppose you could embed some logic in the config.cmake file to pick a different export file for shared or static as well.

>
> Or should there be 2 library targets (something like foo_shared and
> foo_static) and build & install once?

No, this is rather problematic:

1) If your dependencies are built for just one variant as well, then one of those targets could fail.

2) A downstream library may only want to create 1 target, and now it has to add extra logic to decide if it should choose the shared or static target, which is cumbersome.


--

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