| |||||||||||||
Why the KDE project switched to CMake -- and how (continued)Why the KDE project switched to CMake -- and how (continued)Posted Jun 22, 2006 9:46 UTC (Thu) by nix (subscriber, #2304)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.
(Log in to post comments)
Why the KDE project switched to CMake -- and how (continued) Posted Jun 22, 2006 10:41 UTC (Thu) by aleXXX (subscriber, #2742) [Link] > Plus, of course, package vendors will kill you unless the generated> makefiles support at least prefix= or DESTDIR= DESTDIR is supported. > 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. Today KDE 4 builds with cmake on more platforms than KDE 3 with autotools ever did, with full configure checking on all platforms and all compilers/IDEs. Alex
Why the KDE project switched to CMake -- and how (continued) Posted Jun 22, 2006 12:36 UTC (Thu) by akumria (subscriber, #7773) [Link] > Today KDE 4 builds with cmake on more platforms than KDE 3 with autotools> ever did, with full configure checking on all platforms and all > compilers/IDEs.
autotools = automake + libtool + autoconf
What both the two previous posters were pointing out is that if you project is just using autoconf there may not be the same benefit in switching to cmake.
Why the KDE project switched to CMake -- and how (continued) Posted Jun 22, 2006 14:11 UTC (Thu) by aleXXX (subscriber, #2742) [Link] I'm not sure there are many projects using autoconf together withhandwritten makefiles without automake and libtool. CMake has compared to autoconf alone e.g. the advantage that it also supports MSVC under Windows and that it can not only generate Makefiles, but also project files (Xcode, MSVC, KDevelop3), which you cannot achieve with handwritten makefiles. Alex
Why the KDE project switched to CMake -- and how (continued) Posted Jun 23, 2006 3:54 UTC (Fri) by jamesh (guest, #1159) [Link] Some prominent ones that come to mind are Mozilla and Python. There are others, but autoconf is definitely used in more projects than automake (which is no surprise since automake requires autoconf but not vice versa).
Why the KDE project switched to CMake -- and how (continued) Posted Jun 23, 2006 20:13 UTC (Fri) by nix (subscriber, #2304) [Link] Mozilla, Python, GCC, Emacs, XEmacs... the list is long.
A brief scan of the packages I have unpacked here reveals 1319 using Autoconf, of which 835 use Automake.
Why the KDE project switched to CMake -- and how (continued) Posted Jul 10, 2009 10:05 UTC (Fri) by arnuld_uttre (guest, #59526) [Link]
> Posted Jun 22, 2006 10:41 UTC (Thu) by aleXXX (subscriber, #2742)
> Today KDE 4 builds with cmake on more platforms than > KDE 3 with autotools ever did, with full configure > checking on all platforms and all compilers/IDEs.
I read your whole article and the *aloud message* I got was very few KDS developers are familiar with autotools, rather than autotools are not competitive to scons or cmake. And those developers are not willing to learn autotools.
|
|||||||||||||