4 ms·

> And in order to either maintain or upgrade, one needs to know both conventions. No, not really. You only need to know the declarative, target-based modern cm

> And in order to either maintain or upgrade, one needs to know both conventions. No, not really. You only need to know the declarative, target-based modern cmake. Most of the ad-hoc nonsense done with legacy cmake is either features that since the 2.x days were added to cmake, or nonsense that should never have been written to start with.

bdavis__ 4y ago
But you still have to deal with it. It exists!!
chrsig 4y ago
You're missing the point -- it was written and still exists, and still needs to either be maintained or re-written. You can't do either of those things if you don't understand it.
- simplotek 4y ago
  > 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.
kjs3 4y ago
What a fascinating planet you must live on where legacy doesn't exist, or if it does developers can see into the future and know what will be 'nonsense' in 10 years time, or make the whole thing moot because of course they rewrite their build framework for every release of the build system, having unlimited resources at hand. Must be nice there.
tannhaeuser 4y ago
Apart from what sibling commenters say, the problem is that cmake's original syntax was introduced with the same glowing fanatism (over plain old Makefiles) that's now on display with cmake 3.0 (or is it 2.0?) over "old" cmake, making this enthusiasm not quite justifiable. If your old lib can't be build due to a deprecated build system, that's already the greatest possible disaster for a build system, as all your automatic tests etc might not run anymore and you lack a basis for releasing anything at that point. You need to setup an entire new project for recovery.

bdavis__ 4y ago

But you still have to deal with it. It exists!!

chrsig 4y ago

You're missing the point -- it was written and still exists, and still needs to either be maintained or re-written. You can't do either of those things if you don't understand it.

simplotek 4y ago
> 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.

kjs3 4y ago

What a fascinating planet you must live on where legacy doesn't exist, or if it does developers can see into the future and know what will be 'nonsense' in 10 years time, or make the whole thing moot because of course they rewrite their build framework for every release of the build system, having unlimited resources at hand. Must be nice there.

tannhaeuser 4y ago

Apart from what sibling commenters say, the problem is that cmake's original syntax was introduced with the same glowing fanatism (over plain old Makefiles) that's now on display with cmake 3.0 (or is it 2.0?) over "old" cmake, making this enthusiasm not quite justifiable. If your old lib can't be build due to a deprecated build system, that's already the greatest possible disaster for a build system, as all your automatic tests etc might not run anymore and you lack a basis for releasing anything at that point. You need to setup an entire new project for recovery.