[CMake] Proper process for static & shared variants of config packages?

2017-09-01 Thread Robert Dailey
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


Re: [CMake] Proper process for static & shared variants of config packages?

2017-09-06 Thread P F via CMake

> On Sep 1, 2017, at 10:39 AM, Robert Dailey  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-.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