[CMake] actually using cmake alternative to convenience libraries

[Jack Stalnaker]

In the real source code, baz is a thin wrapper for the foo/bar lib. It
combines them into a Python module library, and doesn't really contain any
substantial code of its own.

It's a convenience lib because in the real code, multiple executables and
libs are built from the source tree, and the stuff in lib is common to
most, if not all of these. I could make it a static lib, but it doesn't
need to be installed. I did initially get it working by simply not
installing the lib and setting a POSITION_INDEPENDENT_CODE property on the
static lib, but that didn't feel properly "cmake-ish". I'm trying to
recreate the FAQ's suggestion of simply listing the convenience lib sources.

As for the last suggestion, I was specifically trying to avoid listing the
sources in the top level CMakeLists.txt file. To me, that pollutes the
top-level file with stuff it shouldn't care about. In the likely event that
I have to change the contents of src or lib, I have to change the top-level
CMakeLists, which seems non-intuitive.

I realize all of this sounds incredibly pedantic, since I've found so many
workarounds by now, but I guess I'm trying to get to the bottom of the
CMake crew's vision of how what used to be convenience libs in autotools
should work in CMake. The idea of smashing together a set of common objects
and their dependencies into a convenient partially compiled/linked block
and passing it around without installing it just seems so, well, convenient
and clean, and I am trying to envision the alternative since otherwise
cmake seems so convenient and clean compared to autotools.

--Jack

On Wed, Nov 18, 2015 at 7:16 AM, Magnus Therning <magnus at therning.org>
wrote:

> On Tue, Nov 17, 2015 at 09:37:25AM -0600, 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?
>
> From your text above it sounds like foo.{c,h} and bar.{c,h} don't really
> belong together with baz.c (it's not part of the convenience lib).  So,
> why not separate them?
>
> Another thought, you can always put a CMakeLists.txt in the parent dir
> to lib&src with
>
>     set(foobarSRCS lib/foo.c lib/bar.c)
>
> (maybe with the use of CMAKE_CURRENT_SOURCE_DIR too).
>
> A final questin, why was it a convenience lib in the autotools setup?
> Unless there's really a need to compile the files multiple times the
> whole issue can be side stepped by making it a static lib.
>
> /M
>
> --
> Magnus Therning                      OpenPGP: 0xAB4DFBA4
> email: magnus at therning.org   jabber: magnus at therning.org
> twitter: magthe               http://therning.org/magnus
>
> As we enjoy great advantages from the inventions of others we should
> be glad of an opportunity to serve others by any invention of
> ours, and this we should do freely and generously.
>      -- Benjamin Franklin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151118/18788dc5/attachment-0001.html>