> You're missing the point -- it was written and still exists, No you're completely missing the point. If it exists and needs to be managed then anyone in thei

> You're missing the point -- it was written and still exists, No you're completely missing the point. If it exists and needs to be managed then anyone in their right mind migrates their cmake project to modern cmake. Why? Because odds are any weird thing happening in legacy cmake projects happened because either cmake didn't supported things way back then or old timers made a mess for themselves, needlessly. Maintaining code does not require you to keep messes around. You're expected to pay legacy debt, learn from mistakes, and right whatever wrongs you made. With cmake projects, this means modern cmake. No excuse. > and still needs to either be maintained or re-written. It's not a "or". No one forces you to not fix mistakes. You only keep them around if you wish to, and if that's your own personal decision then the responsibility of creating that problem is on you, not on the tooling. I'm talking from experience. I've maintained a dozen or so legacy C++ projects, some of which with auto tools, qmake, and the deprecated imperative cmake style put together over a decade ago. Porting stuff to modern cmake is trivial. There is no excuse.