Thanks for the excellent suggestion. Unfortunately we can't really use for Visual Studio. The problem is that the two "add_library" calls result in two visual studio projects. The problem with this is that our generated Visual Studio solution already has 300 odd projects, using you suggestion would result in maybe 500 odd. We are already on the limit of projects in Visual Studio before the IDE becomes unusable. We could of course split the software up into multiple solutions but we are very loath to do this.
However it's a great solution for our Ninja builds, so thanks. On Mon, Jul 10, 2017 at 12:09 PM, Petr Kmoch <petr.km...@gmail.com> wrote: > Hi David. > > In your particular case, you don't have build everything twice. Just make > the SHARED libraries thin wrappers around the OBJECT libraries. Like this: > > add_library(obj1 OBJECT a.cpp b.cpp ...) > add_library(lib1 SHARED $<TARGET_OBJECTS:obj1>) > > add_library(obj2 OBJECT c.cpp d.cpp ...) > add_library(lib2 SHARED $<TARGET_OBJECTS:obj2>) > > add_library(combined SHARED $<TARGET_OBJECTS:obj1> $<TARGET_OBJECTS:obj2>) > > Petr > > On 10 July 2017 at 19:41, David Hunter <davidhunte...@gmail.com> wrote: >> >> Currently you can create an OBJECT library using "add_library(<name> >> OBJECT <src>...)" this populates $<TARGET_OBJECTS:name> which can then >> later be used using something like >> "target_sources(name PUBLIC $<TARGET_OBJECTS:name>)". I am wondering if >> there is some reason that $<TARGET_OBJECTS:name> can't be populated when >> you create a shared or static library, for instance using >> "add_library(<name> SHARED <src>...)". Looking at the output the VS 2017 >> generators for "add_library(<name> OBJECT <src>...)" it seems to actually >> build a static library anyway. I suspect that all the <src> files are >> compiled to object files somewhere for both STATIC and SHARED libraries, >> if so would it not be possible to point $<TARGET_OBJECTS:name> as these >> object files? >> >> The reason I ask is that we have a a bunch of source code that builds >> in about 100 projects. These projects have a normal hierarchical >> dependency tree. However when distributing we want to create larger >> libraries that are the combination of various subsets of the smaller ones. >> In automake these are called convenience libraries and I suspect they may >> have been the reason for CMake OBJECT in the first place. Given the >> current >> behaviour we have to build all the projects twice once in SHARED library >> form on once in OBJECT library form. If TARGET_OBJECTS was populated for >> SHARED libraries we would not need to build everything twice as we could >> build everything SHARED but still use TARGET_OBJECTS to build combination >> convenience libraries. >> >> Of course maybe there's already a way to do this without having to >> build twice which I don't know about. > > -- 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
