Ok, my wording wasn't clear: "the lack of disambiguation to cmake of header, static and shared libraries unfortunate"
Yes, as much as I like - in principle - the separate ::static/::shared targets, they are an "innovation" that raises certain questions to which I don't have satisfactory answers, so I felt that the initial cmake-ification should not innovate in this area.
They are definitely not an innovation. That target-based, fully declarative cmake programming was always the end goal of cmake 3. If you read the discussions on cmake-dev that was always clear. Now, I'll grant you that the choice to eliminate as much detail as possible from nonroot CMakeLists is unusual, and could be called an "innovation". However as anyone who has been dropped into mature corporate cmake knows, rootlevel reprogramming of child cmake is both very common and very well understood (search for all cmake stackoverflow posts by my former work colleague Fraser, he taught me most of my low level cmake tricks. Lovely guy too, he lurked here on boost-dev for many years, I don't believe he ever posted). Most would consider rootlevel reprogramming an anti-pattern to be avoided, and normally when you are overriding hard coded decisions in child cmake then it is. But if the child cmake never hard coded anything it didn't have to, suddenly it becomes a powerful form of abstraction and reusability. Well, powerful for cmake at least. But as I've said many times now, whomever ends up implementing this will decide, so much if not most of this discussion is moot and it always was. The real question is who will be implementing this and how far it will be taken within what time frame, and until the proposal lands at the SC and they take a decision, I'm not sure if further bike shedding here is worth anybody's time. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/