On 25/06/2017 13:24, Peter Dimov via Boost wrote:
David Sankel wrote:
I've done a proof of concept for (2), which can be seen here:
Thanks for contributing this Peter. Could you summarize the differences between your proof of concept and Niall's? I think one point of difference is the support for a CMake-based installation of libraries. Is there anything else?
Mine is more or less vanilla CMake, without separate targets for static/shared, and with installation support. I also don't list the header files, just the sources.
I don't see anything in Peter's example which couldn't be implemented in cmake 2.8? It's best practice cmake 2.8-3.0 no doubt, but cmake >= 3.5, I don't think so. I find the lack of clear separation of concerns problematic; the lack of cmake support for header only libraries unfortunate; far too much hard coding of volatile config goes on inside each library; I am unsure how this design would be easily adaptable to C++ Modules support; I don't find this approach particularly reusable by unknown third party cmake, though I can see why Peter will disagree with that. But one or two minor quibbles aside, as a cmake 2.8 design, it's great, and I'd far prefer this approach over what some others have suggested. Indeed its single biggest strength will be its strong familiarity to cmake users, the cmake gurus have done a great job banging the drum on designs like this over what came before. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/