[CMake] Build application suite with dependency checking but single shared libraries without it

[Magnus Therning]

On Sun, Dec 01, 2013 at 01:02:16AM +0100, Tim Grothe wrote:
> Hi Cmakers,
> 
> I'm new to CMake and because every new technology is a bit tricky at
> first, I hope some of you can give me a hint with the following
> build scenario.
> 
> Operating System: Windows
> 
> There are three directories on the same filesystem hierarchy.
> 
> - Include-directory
> - Lib-directory
> - Subversion-workingcopy
> 
> The workingcopy contains around 80 applications and like 900 shared
> libraries and all of those applications can make use of all shared
> libraries and form together one application suite.
> 
> What I'd like to accomplish are the following two scenarios combined
> in one CMake configuration (if possible):
> 
> 1) Build the complete application suite with automatic dependency
>    resolving.
> 
> For this scenario I would think that I put a CmakeLists.txt to every
> folder hierarchy in the workingcopy and add all the necessary
> folders with add_subdirectory(). Because of the many shared
> libraries and the somewhat complex folder-hierarchy I'm not that
> sure about how to manage the dependencies (probably find_package())
> but this should not be the question now.  The header files, libs and
> the binaries should be stored in the Include-Directory,
> Lib-Directory and a binary directory on the same level like the
> other two directories.
> 
> 2) Build a shared library or application on it's own without
>    dependency checking.
> 
> Every shared library and every application is an "independent"
> project.  When building one of these projects the Include-Directory
> and the Lib-Directory should be used when compiling and linking but
> if a dependency is missing or a lib file is out of date this should
> result in a build error in this scenario and the developer has to
> take care of this situation by himself. The created binaries and
> libs should be stored in a subdirectory of the corresponding
> project.
> 
> So I've got an idea about how to solve 1) but I have no idea how to
> solve 2) especially in combination with 1).

Well, what you ask for is, I think, exactly the kind of thing that
CMake is designed to do.  However, given the size of the source base
I'd suggest you initially make it a bit more manageable by identifying
a self-contained subset of one app and the libraries it depends on.
Once you've done that it should be easy to see how to scale it up to
cover the entire project.

/M


-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

"Sendmail" and "make" are two well known programs that are pretty widely
regarded as being debugged into existence. That's why their command
languages are so poorly thought out and difficult to learn.  It's not
just you -- everyone finds them troublesome.
     -- Peter van der Linden, Expert C Programming, p. 220
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20131201/b62ebf4f/attachment.pgp>