Why the KDE project switched to CMake -- and how (continued)
Posted Jun 22, 2006 9:46 UTC (Thu) by nix
Parent article: Why the KDE project switched to CMake -- and how (continued)
One problem with a lot of alternative build system is that autoconf and automake permit substantial end-user adjustment. (Personally I have a rather elaborate config.site setting up compiler and linker options for different systems; embedded hackers tend to have even more elaborate config.site's). Most alternative build systems throw all of that away and provide very little alternative (I remember trying to get Jam to allow user-specified CFLAGS with horror).
Autoconf also embodies a lot of 'ancient wisdom' about detection of features available on all sorts of systems. I haven't found *any* other build systems that come close.
Plus, of course, package vendors will kill you unless the generated makefiles support at least prefix= or DESTDIR=.
Replacing Autoconf at least strikes me as a seriously retrograde step unless you don't care about portability: and I *know* that isn't true for KDE.
to post comments)