[Cmake] separate compiling and linking

[Iker Arizmendi]

The trouble with this approach is that each of
the "components" can use the same filename for
things that are common to most components. For
example, common.cpp or utils.cpp. In addition,
things get a little messier when the components also
make use of flex/bison (which may also have common
names like "parser.y"). In this case the ability
to "encapsulate" each directory's possibly complex
build rules would be useful.

I'd like to get something like this to work:

    SUBDIRS (componentOne, componentTwo)

    # This includes both "regular" object files
    # and objects created through flex/bison
    FILE(GLOB_RECURSE GEN_OBJ_FILES *.o
	${CMAKE_CURRENT_BINARY_DIR}/*.o)

    # Then use something like CMAKE_AR to build
    # the big library. This would result in a few
    # wasted calls to ADD_LIBRARY whose only purpose
    # would be to compile the sources.

At the moment it doesn't seem to work since the file
glob doesn't "wait" for the SUBDIRS directive to
finish building each of the subdirectories. Is there
some way to accomplish this?

Thanks,
Iker





William A. Hoffman wrote:
> You could do something like this:
> LibTopDir CMakeLists.txt:
> 
> INCLUDE(LibComponentOne/CMakeLists.txt)
> INCLUDE(LibComponentTwo/CMakeLists.txt)
> ADD_LIBRARY(BigLib ${LibOneSources} ${LibTwoSources})
> 
> So, remove the SUBDIRS command and only set a list of files in each LibDir.
> 
> -Bill
> 
> At 10:21 PM 4/23/2004, Iker Arizmendi wrote:
> 
>>Given the following configuration:
>>
>>LibTopDir
>>|
>>|--->CMakeLists.txt
>>|
>>|--->LibComponentOne
>>|    |--> CMakeLists.txt
>>|    |--> One.cpp, One.h, ...
>>|
>>|--->LibComponentTwo
>>|    |--> CMakeLists.txt
>>|    |--> Two.cpp, Two.h, ...
>>
>>
>>Is there a clean way to instruct CMake to _compile_
>>component objects in their respective directories
>>but to link them into a single library at the
>>LibTopDir level? I'm currently building a separate
>>library (with ADD_LIBRARY) for each "component" to
>>keep each one's source and build rules isolated from
>>the rest. But in the end all of these libraries are
>>used together by our client applications so it would
>>make sense to just produce a single library instead
>>of having client apps deal with the clutter.
>>
>>Thanks,
>>Iker
>>
>>-- 
>>Iker Arizmendi
>>AT&T Labs - Research
>>Speech and Image Processing Lab
>>e: iker at research.att.com
>>w: http://research.att.com
>>
>>
>>
>>_______________________________________________
>>Cmake mailing list
>>Cmake at www.cmake.org
>>http://www.cmake.org/mailman/listinfo/cmake
> 
> 
> _______________________________________________
> Cmake mailing list
> Cmake at www.cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 

-- 
Iker Arizmendi
AT&T Labs - Research
Speech and Image Processing Lab
e: iker at research.att.com
w: http://research.att.com