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 <mag...@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: mag...@therning.org jabber: mag...@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 >
-- 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