[CMake] acyclic subdirectory builds

[Amitha Perera]

Egon Kocjan wrote:
> I have a complicated situation :). I avoided the kind of approach, that 
> you suggest because it's not modular - main project file contains 
> add_subdirectory commands, which have to be maintained "by hand" - you 
> can see the non-modular information leak here: "add_subdirectory( liba )".

Perhaps we have different definitions of modular.  To me, the main 
CMakeLists.txt file doing nothing more than explicitly enumerating the 
nodes in your graph.  Presumably, that's easy to find, even 
automatically.  In fact, you can think of the add_subdirectory commands 
as the links of a tree-representation of your dependency graph.  The 
target_link_libraries specify the full dependencies *for a given node*. 
   It doesn't get more modular than that.

Instead of listing everything on a top level file, you could do 
add_subdirectory at lower levels.  The issue with this is that the 
add_subdirectory typically corresponds to the build order.  With visual 
studio, it doesn't matter as much, since the IDE will re-order things 
anyway.  Even with Makefiles, CMake is clever enough to put rules to 
make sure dependencies are built first.  However, it's bad practice; 
it's much better if the build order corresponds to a correct subtree of 
your full dependency graph.

That said, you could probably do what you did in your original email by 
using some cache variables to mark a directory as already processed. 
This may require CMake 2.6, since the reading and writing of cache 
variables occurs in different phases in CMake 2.4.

> It would be nice to double-click on any project 
> in the graph and have the build system figure out the needed 
> dependencies from "lower" levels automatically. The reason that I want 
> to have subgraph builds is that VS would probably break if I included 
> the whole beast at once :).

This is what I referred to in my post when I wrote about "self-standing 
sub-project solutions".  Since you are beginning this CMake adventure, I 
strongly suggest you begin at CMake 2.6.  It fixes many, many quirks of 
2.4.  If, for example, you did

exea/CMakeLists.txt
   project( exea )
   ...
   add_executable( exea .. )
   target_link_libraries( exea liba libb )
   ...

You would (also) have a solution called "exea.sln".  Opening this would 
get you exea, liba, libb, and all of liba's and lib's dependencies. 
Pretty modular, I think.

If exea depends exclusively on a library libc, then you could add

exea/CMakeLists.txt
   ...
   add_subdirectory( libc )
   ...

and "hide" libc from the other targets, maintaining your modularity. 
However, if both exea and exeb depend on libc, then I don't think it 
makes sense for each to pretend that libc is "hidden".  From an overall 
build perspective, I think it's better to list libc *one* somewhere 
(e.g. at the top level), and just refer to that in exea and exeb.

On a philosophical note, I think you'll find that once you approach the 
problem in the CMake way (as opposed to forcing CMake to do it exactly 
as it was done before), you'll find that it works just as well.

 > The task is to convert ~100 projects with acyclic (non-tree)
 > dependencies to cmake.

I'll repeat again that the target_link_libraries is really what captures 
this dependency graph.  add_subdirectories is simply an enumeration of 
the nodes.  Ideally, the execution order of the add_subdirectories 
matches one of the tree traversals of your dependency graph, but it 
doesn't have to.  And I strongly suggest that you start with CMake 2.6. 
  It is at a release candidate stage now, but the issues that are being 
fixed are pretty complex corner cases that will not affect you getting 
your build system using CMake.


Cheers,
Amitha.