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. 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.)
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.