That's why I've said "not just distribution guys".
Posted Nov 10, 2011 6:32 UTC (Thu) by khim
In reply to: That's why I've said "not just distribution guys".
Parent article: libabc: a demonstration library for kernel developers
Cons was fairly slow, but not more so than autotools.
Sadly this is not true. Autotools scale, scons does not - it's that simple.
CMake is quite fast.
Yup. That's why I'm not concentrating on speed when I discuss "modern build system". Some of them can be rejected outright for that reason alone, but some of them are fast.
I don't see why cross-compilation would be any harder (or easier) on CMake versus autotools.
It's harder with SCons. CMake actually somewhat acceptable here. The fact that cross-compilation was added so late is still felt sometimes, but yes, the difference is not that large today. It's still large enough to be a pain, though.
In the same way, autotools standardization is a mirage because everyone uses a slightly different set of macros and generator programs.
Sure, but there are big difference: I can not drop init script from Debian in RedHat and hope that it'll work. I can add any autoconfiscated project in my own project - and that works (sometimes with minor issues, but it works).
And so, on as we discussed.
And as discussed it's minor issue. I'm deeply involved (enough for that difference to matter) with just a couple of projects. Ok, may be half-dozen, but still enough to count them on my hands. But I'm using many dozens of different other projects and they all looks the same from the outside: "./configure ; make ; make install".
If you are going to recommend that people use an inferior build system because of compatibility and the difficulty of retraining, you should also recommend that they use SysV init, for the same reasons.
Nope. As I've said: all "new" init systems (upstart, systemd) have support for "old" SysV init scripts - and they had SysV init compatibility support from the day one. They understand that they must support "old way" of doing things till "new way" takes over. Transition takes years - and all that time old way should be supported seamlessly. Autotools compatibility in build systems either does not exist at all or is an afterthought. The question arises: if developers of these systems can not make even such fundamental thing "right" then what can they do right? And indeed - there are numerous other shortcomings in these build systems.
In fact, whenever systemd comes up in a discussion, you see a lot of posts by system administrators who are scared of the change-- and rightly so.
Sure. And then you see a lot of posts where they are relived to find out that they can still use most their SysV init tricks with systemd.
But guess what - positive change can never happen when people refuse to learn something new.
Sure. But positive change can and should happen piecemeal. People must have the right to learn "something new" at their own pace. Sometimes (when change is big like with pulseaudio or systemd) disruption is inevitable - but the authors should still try to reduce it as much as possible. Build system creators stance is "forget everything you knew, you should learn our new system right away" - and this just will not do.
For example cross-compilation: I can not use my usual way (./configure --target=blah-blah-blah"). Instead I must learn to write .cmake files right away. Why? I can understand the desire to get rid of M4. Ok. But why get rid of all the amenities offered by autoconf at the same time? Ah, you want to "build new world free from problems of the old one". Ohkay. That's you choice. If you just want to create bunch of new problems - you can do that. Just... do that somewhere where I'm not involved, Ok?
to post comments)