[CMake] Handling library dependencies and minimizing duplicated include_directories

[Tyler Roscoe]

On Mon, Mar 22, 2010 at 05:47:15PM -0700, Aaron_Wright at selinc.com wrote:
> So... no easy answer for this? The only reason I bring this up is that 
> I've looked at the cmake version of boost, and it requires a library of 
> several cmake files full of macros and functions that help get their 
> project organization to work with cmake. I've had to resort to the same 
> kind of thing. ADD_LIBRARY just didn't cut it. I like that cmake allows me 
> to get to the functionality I want, but it seems that it becomes a 
> scripting language at that point, and cmake is certainly not a scripting 
> language. Boost for example has numerous helper functions or macros for 
> using named arguments with macros and functions. (They are all very 
> cleaver and I totally use them in my project.) Another example is that my 
> project has functions and macros for adding the dependencies between 
> libraries, dependencies like include directories, link directories, and 
> link libraries. Is there something on the horizon for CMake to address 
> these issues? Or have they been addressed, but I've missed them?
> 
> On a side note, I see questions for this kind of thing all the time on 
> this mailing list. I never see a very good answer. Perhaps a wiki page or 
> a blog could be made covering project organization. It could perhaps cut 
> down on repeat questions.

My take on this is that every build system is a little different. Weird
organic organization builds up over time. Different groups have
different requirements. Different compilers and platforms require
slightly different approaches. As such, it's hard to write a "one size
fits all" solution.

So I think the only way CMake can succeed is by providing fundamental
building blocks and letting build engineers put those pieces together
into a whole that suits their needs.

I *do* think of CMake as a scripting language, one that's tuned for
modelling builds and perfomring common activities related to builds
(manipulating files, calling external scripts).

That said, I agree the Boost stuff is interesting and once it matures, I
hope we can find a way to absorb those concepts into CMake proper. Kind
of like how the Boost libraries are experimental additions to C++ that
are (sloooooowly) migrating back into the C++ spec.

I also agree that the wiki could be expanded with more examples of
common practices. The archives for this mailing list are sprinkled with
fantastic examples from some experienced developers but it's not always
easy to find what you're looking for.

tyler