[CMake] CMake for many interdependent libraries/executables

[Gerhard den Hollander]

What we did here, faced with the same issue,
is have an automated, ightly build that builds everything,
and then have partial checkouts.

The cmake link dependencies then first check if there is local source
and local libs, and if so uses those, otherwise it takes the nightly
build libs.

A bit of a pain to setup, but once it's setup (which was 5 years orso
ago), it is a blessing.


> >> We don't modify external dependencies, but we do need to check them 
> >> out and build them before building a library or executable that depends on them.
> >> Sometimes a developer will be working in a single library or executable.
> >> Sometimes he will be working in multiple libraries and/or executables.  
> >> You can imagine that for a new developer it becomes very complicated 
> >> to know which libraries and executables need to be checked out and in 
> >> which order they need to be built in order to satisfy all the 
> >> dependencies.  Even established developers that have all the necessary 
> >> dependencies checked out and modify a library have trouble knowing 
> >> which libraries need to be rebuilt, and in what order, for the change to propagate up to an executable.
> >
> > How impractical would it be to always check out and build everything?
> > How close is an incremental build over the whole tree to "fast enough"?
> > - Dan
> 
> Some of our external dependencies (e.g. boost) are quite large and can
> take a very long time to build.  We also have several different customers
> that each get a different set of executables, but those executables all
> make use of some subset of the same libraries.  Occasionally we need to
> switch from working for one customer to another and it is nice to not
> have separate workspaces (and thus avoid duplicate code and data files
> on disk).  So the short answer is it is not very practical to always
> check out and build everything.
> 
> It's hard to say how fast an incremental build is over the whole tree.
> It has always been a manual process.  In my example, if I changed liba
> I would have to build it, build libb, build libd, and then build exe2.
> Each of the individual builds were usually a couple of seconds so I
> imagine that an incremental build over the whole tree would just be
> a few seconds per node on average (hopefully faster if nothing actually
> changed).
> 
> I realized that I didn't explicitly mention this, but each library and
> executable has its own repository and is currently treated as its own
> project as far as the makefiles/VS solution files are concerned.  I
> would like to keep it that way but be able to have the option of the
> "superbuild" for each project that would take care of the current
> project and all its dependencies.  Each depender could thus call each
> of its dependees' "superbuild."  I think that would allow a developer
> to be able to work on a given library in isolation without needing to
> have all the projects that depend on it checked out, yet still allow
> another developer working on a different project that depends on that
> library to easily check it out and build it.
> 
> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
Kind regards,
Fugro-Jason Netherlands BV

Gerhard den Hollander
AE Technical Support Manager

Telephone: +31 (0)70 3170 539  /  Fax: +31 (0)70 3170 511
E-mail: gdenhollander at fugro-jason.com  
	/  Website: www.fugro-jason.com <http://www.fugro-jason.com/>
Address: Veurse Achterweg 10, 2264 SG Leidschendam, The Netherlands  /
P.O. Box 35, 2260 AA Leidschendam, The Netherlands
Trade Register Nr: 24294747  /  VAT: NL 8080.15.163.B.01