[CMake] actually using cmake alternative to convenience libraries

Jack Stalnaker jack.stalnaker at gmail.com
Tue Nov 17 14:46:38 EST 2015


I read about those, but they don't seem to provide a way to add linked in
libraries, so it didn't seem to add a lot over a list of sources. In
autotools, you could bind your convenience lib with any dependencies via a
LIBADD primary, and the added libs would automatically propagate to the
final target. This of course works in cmake if I build a real library, but
if I try to link a library (e.g. say the system math library) to the object
library, cmake tells me it cannot do that for object libraries. In that
case, it seems like I still need to create the foobarLIBRARIES variable to
provide to target_link_libraries later.

Am I missing something, or is there a way to somehow attach the necessary
external libraries to the object library as well?

Thanks,
--Jack

On Tue, Nov 17, 2015 at 11:14 AM, Bill Hoffman <bill.hoffman at kitware.com>
wrote:

> On 11/17/2015 10:37 AM, Jack Stalnaker wrote:
>
>> I'm trying to figure out the best way to handle something that was a
>> convenience lib under autotools. I realize that there's a FAQ entry here:
>>
>>
>> https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F
>>
>> But its terse 2 paragraphs don't say how to actually do what it
>> suggests. My problem is this. I have this source tree:
>>
>> lib
>> |--foo.c
>> |--foo.h
>> |--bar.c
>> |--bar.h
>> |--baz.c
>> src
>> |--goo.c
>>
>> In lib, I need to somehow collectively refer to foo and bar. Okay, so I
>> can create a variable:
>>
>> set(foobarSRCS foo.c bar.c)
>> set(foobarLIBS ${externalLibFound})
>>
>> which is what the FAQ entry seems to suggest. However, this variable is
>> not visible to goo.c. Okay, so as an alternative, I can do this:
>>
>> set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc.
>>
>> but now the variable is not visible to baz.c, which also must include
>> the srcs to create a module library called _baz! I can of course do
>> something like this:
>>
>> set(foobarSRCSLOC foo.c bar.c)
>> set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE)
>>
>> but this feels dirty and repetitive.
>>
>> I also realize that I can just create the variables in src, but that
>> kind of defeats the entire purpose of walling of the common libs and
>> their dependencies in the first place.
>>
>> Is this the right way to work, or am I missing something simple?
>>
> There is a new feature to do that:
>
> https://cmake.org/Wiki/CMake/Tutorials/Object_Library
>
> --
> Bill Hoffman
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY 12065
> bill.hoffman at kitware.com
> http://www.kitware.com
> 518 881-4905 (Direct)
> 518 371-3971 x105
> Fax (518) 371-4573
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151117/bc354a3a/attachment.html>


More information about the CMake mailing list