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