The point in "modern cmake 3" if you will, is that I write:
find_package(boost_foo) target_link_libraries(myLib boost::foo)
And this will work whether boost_foo is header-only or compiled static or shared. Not only that, but if boost_foo or one of its dependents change from being header-only to being compiled(or vice versa), build scripts to boost_foo or any downstream libraries do not need to change.
This is the usefulness of exporting usage requirements with build systems, and why it is important in cmake 3. What you are proposing does not provide this usefulness and is a major step backwards.
Where are you getting the notion that end users want to not care whether their dependencies are in header only, or static, or shared form? They're the ones suffering the build times. Of course they take strong opinions on it, they'll choose exactly one and contract into it permanently. They do not want you the library dev messing with that. That's why your proposed cmake 2-ish "directory per build config" system makes zero sense to me. Nobody in end user space wants to be mucking around on the command line with twenty lines of -Dvariable=setting and dealing with binaries being named weird things the library dev chose, in weird paths the library dev chose. They want to bring in the cmake for the library they're adding, and specifying *exactly* what presentation of that added dependency they are *contracting* into at the point of import, not separately on a command line with some voodoo magic list -D variable settings. *That's* cmake 3. It's reusable, it's a generic driver for external third party unknown cmake. Your proposal is exactly opposite that: you the library dev enforces what you think the end user wants by serving them a rigid menu of what you think is right for them. Regressive. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/