[CMake] Approach to both shared and static lib (again, sorry)

[Jacob Barrett]

The Apache Geode Native [1] project needs to build both the shared, for
releasing, and the static, unit testing and embedding in mix-mode .NET
assembly. We tackled this by creating an INTERFACE library [2] that
contains the common elements of both shared and static then having SHARED
[3] and STATIC [4] libraries include the INTERFACE as a dependency. We also
put the static and shared library CMake files in separate directories so
that Cotire [5] would work.

 It isn't perfect but it works pretty good. The biggest downside is that
the INTERFACE target can't contain the sources. So at the parent CMake file
we jam all the sources in a variable for the children libraries to consume.
Something like this, details in the links below.

mylib/CMakeLists.txt:
add_library(INTERFACE _mylib)
target_link_libraries(_mylib INTERFACE Boost::Boost ...)
target_...(_mylib INTERFACE ...)
set(MYLIB_SOURCES mylib.hpp mylib.cpp ...)

mylib/shared/CMakeLists.txt:
add_library(mylib SHARED ${MYLIB_SOURCES})
target_link_libraries(mylib PRIVATE _mylib)

mylib/static/CMakeLists.txt:
add_library(mylib-static STATIC ${MYLIB_SOURCES})
target_link_libraries(mylib-static PUBLIC _mylib)
target_compile_definitions(mylib-static PUBLIC MYLIB_STATIC_DEFINE)

If you check out the links below for details please provide some feedback
on improvements we can make. There is lots of stuff going on in these files
to support Cotire and some platform differences we couldn't find a better
place to deal with. There is also some funkiness with include directories
that I haven't investigated fully.

Would love to hear that there is a better or modern way to attack this
problem.

[1] https://github.com/apache/geode-native
[2]
https://github.com/apache/geode-native/blob/develop/cppcache/CMakeLists.txt
[3]
https://github.com/apache/geode-native/blob/develop/cppcache/shared/CMakeLists.txt
[4]
https://github.com/apache/geode-native/blob/develop/cppcache/static/CMakeLists.txt
[5] https://github.com/sakra/cotire

-Jake

On Sat, May 19, 2018 at 6:00 AM Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> I know this has been asked before, but I've never seen a really
> authoritative answer.
>
> Say I have a simple single-library project.
>
> The advise I've seen is to not pass SHARED or STATIC to the
> add_library(..), but instead let the user pass
> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> or static.
>
> That's fine, but leads to packagers having to do ugly things like e.g:
>
>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>
> That is, do two separate configure/build/install, in order to get both
> a shared and static version. Note that the above was just an example.
> But many packagers do it like this.
>
> How can I make life easier for the packager?
>
> I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
> add_library(...), one with SHARED and one with STATIC, but the same
> input source files. I could give the two libraries different output
> filenames, as to not conflict on e.g. Windows (where I think the .lib
> import library containing symbols for the .dll would otherwise
> conflict with the static library .lib, or..?).
>
> To not have to repeat the list of sources, I could keep them in a
> variable. But that's not recommended in modern CMake AFAIK.
>
> I've also seen people add an object library, and then build the shared
> + static lib from that.
>
> What are your thoughts on all this? How do you go about it? Do you use
> the recommended way, with a single add_library(..) and just let
> packagers put up with having to do two builds?
>
> Thanks in advance!
> Elvis
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180519/5e5525ca/attachment-0001.html>