Boost logo

Boost :

Subject: Re: [boost] Status of the CMake-ification
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-11-17 13:04:56


On 11/17/15 9:24 AM, Alex wrote:
> I was doing a bunch of work composing existing (non-Boost) CMake
> projects to be used as "submodules" in multi-module projects. I found
> that most CMake projects in the wild are almost impossible to compose if
> they weren't written with the composeability in mind from the start.
> Stuff like silently rewriting flags, changing output dirs, rewriting
> files in source dir (zlib is doing so) etc prevents the reuse. I ended
> up using new custom CMake scripts (based on existing CMake scripts, with
> the obvious burden to maintain them) for most of the projects.
>
> Just my 2 cents.

Well, that's a lot more than 2 cents worth. It's very typical that
projects seem to be a lot easier to do until you actually try to do them.

Personally, I don't think we need to go "the full monty" in order for
such an effort to be useful. If I could easily just one build one
project at a time for cmake (as I can for the serialization library) I
would be happy with that. I would be quite satisfied even if I had to
manage the dependencies in my own brain. For example, I'd like to
library X in my code for a medical device. So I'd like to run the tests
on X and all the libraries that that X depends upon. I would be
perfectly happy to just figure them out "by hand" and run them each by
hand. This would be pretty simple. Others - making a website for
example - wouldn't need this level of testing so they could might just
test the library X or just skip the whole build/test step entirely. Of
course each library would be different - as the documentation is now.
That's not ideal. But I still think there's a good case to be made that
library authors who want to can add CMake files to their libraries.
Eventually, someone might come up with the magic to make them
composible. This would be great but it's not necessary to make the
effort worthwhile.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk