Non OBJECT libraries and population of $<TARGET_OBJECTS:..>

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

Non OBJECT libraries and population of $<TARGET_OBJECTS:..>

davidhunter22
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
Reply | Threaded
Open this post in threaded view
|

Re: Non OBJECT libraries and population of $<TARGET_OBJECTS:..>

Petr Kmoch
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Non OBJECT libraries and population of $<TARGET_OBJECTS:..>

davidhunter22
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 <[hidden email]> 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 <[hidden email]> 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