[CMake] Unify entire tree into a single static library?

Doug douglas.linder at gmail.com
Wed Feb 23 00:47:54 EST 2011


Hi,

If this has been answered somewhere already in the WIKI or something, please
just link me up; it seems like a simple question, but I can't figure it out.

So, basically I have my code split into a series of sub-directories:

project/
project/utils/
project/common/
project/desktop/
etc.

Each sub directory currently has it's own CMakeLists.txt, as follows:

file(GLOB SOURCE *.c)
add_library (shared ${SOURCE})

The parent CMakeLists.txt file define these as dependencies:

# Shared code
include_directories("${PROJECT_SOURCE_DIR}/shared")
add_subdirectory(shared)
set (EXTRA_LIBS ${EXTRA_LIBS} shared)

# Utility libraries
include_directories("${PROJECT_SOURCE_DIR}/utils")
add_subdirectory(utils)
set (EXTRA_LIBS ${EXTRA_LIBS} utils)

...

# Source files~
file(GLOB sources src/*.c)
add_library (project ${sources})
target_link_libraries (project ${EXTRA_LIBS})

This builds fine. However, it generates a library.a file for each directory,
eg.

per-ms006:build douglasl$ du -a |grep "\.a"
./desktop/libdesktop.a
./libcommon.a
./shared/libshared.a
./utils/libutils.a

The problem is that if I want to depend on this with an external project, I
can do so via this:

# Add lib
include_directories("/path/to/project/include/")
link_directories("/path/to/project/build/")
set(EXTRA_LIBS ${EXTRA_LIBS} project)

...but....... obviously this does not link any of the other sub libraries
like -lutils -lcommon -ldesktop, so my build fails with a pile of undefined
symbol errors.

So, what's the way to solve this?

Can I either:

1) Somehow depend on an external project directory with some kind of
add_subdirectory() directive?

2) Somehow force cmake to combine all the symbols into a single static
library for the project, rather than several individual ones?

(The only suggestions I've seen so far are (2), where you define a single
CMakeLists,txt and list _all_ source files in all directories in it. This is
a silly solution, or (2) where you manually uncompress the .a files and
recombine all the .o files into a single .a file. This is also
just ridiculous. Surely this is a problem that comes up a lot...?)

Cheers,
Doug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110223/6527e47e/attachment-0001.htm>


More information about the CMake mailing list