4 ms·

> It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake (...) No. "Legacy cmake" has been made obsolete with

> It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake (...) No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style. I'd go as far as claiming that 95% of all use cases boil down to simple straight-forward one-liners with modern cmake, with the remaining 5% corresponding to putting together custom cmake find modules, packaging, and deploying runtime dependencies. > (...) now there need to be two more languages (slide 13) (...) I'd argue that if anyone feels the need to write scripts to do something in cmake, they are already doing something awfully wrong to start with.

chrsig 4y ago
> No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style. "made obsolete" != expunged from codebases. I'm sure there are plenty using cmake 2.x conventions that haven't been updated, and need maintaining. And in order to either maintain or upgrade, one needs to know both conventions.
- simplotek 4y ago
  > 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.
palata 4y ago
This ^. I seems common for people to try to have CMake run Python scripts, install stuff on the system, and do all sorts of custom tasks. I'm sure other build systems also allow devs to make a mess if they want to. Maybe some are less powerful, so that people cannot make such a mess even if they want to. But "the tool is too powerful, I will shoot myself in the foot because I don't want to learn the basics" does not sound like a good argument to me.
- KurvaKing 4y ago

chrsig 4y ago

> No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style. "made obsolete" != expunged from codebases. I'm sure there are plenty using cmake 2.x conventions that haven't been updated, and need maintaining. And in order to either maintain or upgrade, one needs to know both conventions.

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

palata 4y ago

This ^. I seems common for people to try to have CMake run Python scripts, install stuff on the system, and do all sorts of custom tasks. I'm sure other build systems also allow devs to make a mess if they want to. Maybe some are less powerful, so that people cannot make such a mess even if they want to. But "the tool is too powerful, I will shoot myself in the foot because I don't want to learn the basics" does not sound like a good argument to me.

KurvaKing 4y ago