On 5/20/16 6:25 AM, Peter Dimov wrote:
alex wrote:
But if boost can’t make this trivial change to better support cmake, then it would be hopeless for future changes in boost for better cmake > support.
I don't really have a stake in this, but I think this is the reason why this discussion is so awkward. It seems that 'CMakeLists.txt' is seen by both opponents and proponents as a foot in the door for future changes in Boost for better cmake support.
Yes. Yes again.
Incidentally, and ironically, a CMake-ified Boost that duplicates our current Boost.Build setup would probably have its CMakeLists.txt files in build/, so that the top level can glob for build/CMakeLists.txt. Globbing for CMakeLists.txt finds too many subdirectories you don't really want to find. (And status/CMakeLists.txt will glob for test/CMakeLists.txt, perhaps.)
At least the way I use CMake this isn't a problem. I just point the GUI to the top CMakeLists.txt file whereever it happens to be. Simple as pie.
I can understand existing library maintainers being worried about having to support cmake in the future (or risk looking arcane).
Speaking for myself, I have no problem at all with supporting cmake at some point in the future, if necessary.
Right. If more new library authors support it, and more users expect it, And standard customs evolve and perhaps a CMake Template for making scripts gets written and perhaps someone writes a document on CMake customs and best practices with regards to Boost, it will become a defacto requirement. QuickBook has a similar history. Having or not having a CMakeLists.txt file at the library root won't matter either way. Robert Ramey