[CMake] Two questions...

[Brad King]

Lars Pechan wrote:
> Hi there,
> I'm in the process of trying to port quite a large legacy multi-platform 
> makefile project to CMake. A couple of questions have popped up:
> 1) Quite far down in the tree is a directory which is built differently 
> with regards to compiler switches, include paths and defines. CMakes 
> recursive inheriting of those variables leave me with a set of options 
> by the time I get to this tree that simply won't work. How can I reset 
> these for a new subproject? Or should I do that dir as a separate 
> project and then bring in the library that is produced there by means of 
> some nifty dependency trick? Changing the original directory structure 
> is not an option.

Currently it is not possible to clear these settings.  We do plan to 
change the way these commands work to make this possible, but it is not 
yet implemented.  For now you will probably have to build that directory 
as a separate project.

> 2) On MacOSX I get various link errors. Basically what I have is a 
> number of subdirectories that each contain a part of the project. I 
> build a (static most of the time) library in each such dir and the try 
> and link them all together at the top level.

CMake methodology allows dependencies only on parent and previously 
listed sibling directories, but not on children.  If you have an 
executable at the top level linking libraries from below then 
dependencies are not setup correctly and the build might not always 
finish with everything up to date.  This ordering limitation is 
historical and will eventually be eliminated.  For now you will have to 
add a subdirectory at the top level that is listed after all the others 
to build the executable:

SUBDIRS(libsrc1 libsrc2 ... exesrc)

This doesn't mean you have to move the source files for the executable. 
  They can be referenced from exesrc/CMakeLists.txt like this:

${MYPROJ_SOURCE_DIR}/src1.cxx

 > Sadly, g++ produces link
> errors (undefined symbols) relating to files that are definitely in one 
> of the static libs (and, of course linked in via 
> TARGET_LINK_LIBRARIES(...)). In this particular case I can easily see 
> that the errors are pertaining to two different statically linked libs 
> from further down the tree.
> 
> However, interestingly, if I change the link line so that these two dirs 
> are included as .a-files with absolute paths it links just fine. Eg
> 
>  From CMake:
> 
> g++ -Ltop/Sub1 -Ltop/sub2/ -Ltop/sub3 -ls1 -ls2 -ls3 ...
> 
> produces undefined symbols pertaining to libs2.a and libs3.a. If I then 
> change the command line manually to:
> 
> g++ -Ltop/Sub1 top/sub2/libs1.a top/sub3/libs2.a -ls3 ...
> 
> it links just fine.
> 
> Any ideas of why this is? And also, more importantly, is there any way 
> for me to express this style of linking in CMake? (I tried adding the .a 
> files to the ADD_EXECUTABLE but that won't work. I also tried to tweak 
> TARGET_LINK_LIBRARIES to no avail)

If you list the full paths to the .a files then I think the entire .a is 
copied into the executable, even the .o files that are not used (at 
least on some platforms).  This is why CMake always splits up the path. 
    The unresolved symbols are probably happening because the order of 
the libraries is incorrect or there is a circular dependence between the 
libraries' references.  Switching the link order or listing the 
libraries twice can resolve each of these issues, respecitvely.

> While I'm at it, sorry if this is too trivial for the list, but I would 
> like to pre-populate CMakeCache.txt with appropriate CXX_FLAGS etc using 
> the option to pre-initialize the cache with 'cmake -C'. I'm already 
> populating some settings this way but I'm not sure how to set the 
> compiler flags?

You should just be able to put

SET(CMAKE_CXX_FLAGS "myflags" CACHE STRING "C++ compiler flags")

in the initial cache file.

-Brad