This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling!
I disagree here. There is nothing unusual in theory for creating a header only library which needs to link to a non-header only library, whether that non-header only library is a static library or a shared library. The choice of a header only or non-header only library should not be predicated on whether or not any other library on which it depends is header only or non-header only.
I think this the crux of the misunderstanding. cmake doesn't implement header only library support as you and Peter appear to understand it. It implements INTERFACE targets. These are, quite literally, targets wholly composed of nothing. They cannot contain sources. They can inject paths to search for headers, compile and link flags into things which consume them. That's it. So when I've been speaking of implementing header only library support into cmake, I really mean targets consisting solely of how to find interface files, and how the final binary ought to be compiled and linked to keep the header only library happy. No non-wholly-interface-file dependencies permitted, though you can inject linking to arbitrary system or other libraries. The target dependency graph is *pure*.
Furthermore, and most obviously, a non-header only library may have a great portion of its code as header only and just a small portion of its code as being built into a static or shared library. So another header only library might depend on a non-header only library, but could depend on only the code in the non-header only library which is header-only, or conversely could depend on the code which is part of a static or shared build of the non-header only library. And those dependencies could change as the design of a header only library evolves.
All of which is fine if you adhere to the rule that header-only libraries with static or shared components or dependencies do not claim to be header-only. They claim themselves to be static or shared, as appropriate. There are quite a few libraries in Boost which are pure header only and with no dependencies on anything but other header only code. It is to these I refer only.
Given all these very real possibilities, none of which should be important in forcing an actual design of a header only library, I find it absurd to "stop compiling" simply because the design of a build system is too simplistic to deal with the variations.
The whole point of a decent build system is to refuse to build when requirements and/or guarantees have been broken. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/