Luca Barbato - Latest comments on cmake vs autotools, a benchmark

In response to: cmake vs autotools, a benchmark

Luca Barbato [Member] — Tue, 14 Apr 2009 16:51:36 +0000

You can add up autotools + actual autotools code (*.ac *.am *.m4) or just the generated code (Makefile.in configure) and maybe make. You may do the same with cmake as well. If you start thinking about how big something is I'd say right now cmake is about 3-4 slots of autotools...

The fact cmake is built on c++ just makes it having one more dep, nothing more, nothing less.
the fact it's about 5 times the size of the autotools... Again it's just something you may or may not consider, you claim about 500k for the autotools generated files + autotools code + m4 bundles for a simple project, even if a simple project won't need additional m4...

You may love your new shiny toy and you may mock kids using vintage ones or you may just try find where a tool is better and where you can improve the other and try to use the one that works best for you for a specific task.

For wesnoth apparently autotools at least here works better and since autotools is what comes from the rest of the toolchain doesn't add up. Since I do not use cmake it does add up for wesnoth and it takes some more to get the same program. In the end I'd like to have wesnoth built by autotools (even better built by bash + make as that's what autotools gives you) instead of cmake since it works better for me.

In response to: cmake vs autotools, a benchmark

Maciej Mrozowski [Visitor] — Tue, 14 Apr 2009 15:03:24 +0000

Diego, maybe it's just the way (somewhat offensive maybe?) you presented your point of view, you know - there are some people with "offensive" attitude on gentoo-dev and you imagine how reception looks like.

>> Also having over 500KiB of buildsystem
>> scripts for simple hello world-size project
>> is pretty ridiculous, don't you think?

> dev-util/cmake-2.6.3: 429 files, 25 non-files, 24923.813 KB
> Absolutely.

If it wasn't clear enough - I meant buildsystem files distributed with *project* itself - so you should compare several CMakeLists.txt files with shipped .cmake modules with aclocal.*, Makefile.* and configure* scripts (and libtool files of course as well).
But following your logic, equery list automake shows four different versions slotted, what about this?

I guess your (Diego and Luca) main objections are:
- presence of C++ compiler
- dependency on libstdc++
- not robust bundled cmake modules
- cmake depending on xmlrpc-c can be fixed on Gentoo side if it really hurts you that much
- umbrello depending on kdepimlibs and thus akonadi was not upstream fault but Gentoo devs layness and I fixed it already in case you missed
- RPATH issues - well, those are just bugs that should be fixed - Niemand ist perfekt, right?

So it just leaves us with general C++ rant and insufficient cmake bundled modules (valid point imho).

In response to: cmake vs autotools, a benchmark

Diego E. “Flameeyes” Pettenò [Visitor] — Tue, 14 Apr 2009 10:24:23 +0000

Sorry but if they are just a "quickstart", it is a *seriously stupid* way to provide support do buildsystem, because then you get 10 projects with at least 8 different modules to do the same bloody thing. Sure there is the same problem with autotools, but it really does not solve anything.

Why, why, why, why. Why X11 team is doing that? Because they haven't followed my advice I gave more than an year ago, maybe even two years ago. Yes, it might sound strange to you but it happens that following the advice of somebody that knows some topic better than you can usually resolve problem. Why does it take weeks to convert mysql? _Because they bloody idiots in MySQL did not write autotools!_ they wrote crap based on autotools, which is the same that KDE did with 3.5 series.

Sorry but autotools are just an old relic as much as the presence of commandline is: it's always said by people who like shiny stuff and just that. Sure I'd love if we were able to replace autotools but cmake is not up on par yet.

By the way: why did KDE 4.2 require akonadi to install umbrello? Wasn't that a buildsystem issue after all?

illogic-al: you should never have messed with the libtool script in the first place; nor with Makefile.in; if you did it means that either you found bugs (which would be the same as messing with cmake original source code), or you were doing something seriously wrong. As for the problem being simply FindRuby, have you checked FindJNI yet?

Oh yeah but cmake just provides a basis, I forgot, all the rest of the world has to reinvent stuff, because the _one big huge issue with autotools_ (the presence of N different variations of m4 files) is left untouched, for the nostalgic I guess.

What autotools seriously have lacked for a long time, and caused a critical mass of crappy buildsystem to spawn, is documentation. CMake seems to have had Kitware to push through by writing the buildsystems or instructing people to in the first place. The fact that KDE is taken as an example is probably the only reason why it can be used.

Point is: KDE 3 had a seriously crappy (and very flawed) build system, and lots of people copied from that instead of using autotools properly. Which is why we got so many broken buildsystems out there. Fixing an issue in a properly-written buildsystem usually take me five minutes; ask Lennart, for whom I fixed a pulseaudio build regression before he took the plane for BOSSA.

Only practical reason to choose CMake over autotools is Windows support. And I can accept that well, what I find stupid is to say that it's _perfect_ and it has not to change. That's simply stupid.

Oh by the way the FindRuby module which is broken I reported basically immediately after I first tried CMake since I wrote a better one than the one shipped at the time (which was simply not working); the report was ignored until a kde.org guy submitted a different version; why? why? why?

Yeah sure, keep on f*cking trying.

In response to: cmake vs autotools, a benchmark

Luca Barbato [Member] — Tue, 14 Apr 2009 06:56:16 +0000

Maciej Mrozowski

> Find${PKG}.cmake modules bundled with cmake are mentioned (in Documentation) to be simple and "quickstart", rather > than reliable robust solutions for production - so your argument is quite invalid here, Diego.

Basically you are telling me that you have to redo the equivalent of your .m4 files provided since they are bogus?

> What's the most important in CMake - it's much harder to write bad cmake script rather than bad autotools/automake
> /libtool script.

Seems you autocountered this statement telling you have to rewrite basic checks since they aren't provided by default...

> If autotools are that great, easy and all, then why don't we see yet mysql and openldap split ebuilds in tree?

Because upstream want things differently and you try to address upstream in order to have some agreement before gutting their application randomly mostly. Then, as Diego pointed for mysql, you may have other issues regarding
how things are built that are to be fixed.

> Why does it take weeks to covert libmysqld from static to shared library?

Same reason as before.

> Why X11 team is currently fighting with xcb ABI change consequences caused by broken by design libtool files? (.la)

Because nothing is perfect? Because libtool isn't that necessary anymore and could/should thinned a lot on systems that can do without it IMHO.

> Also having over 500KiB of buildsystem scripts for simple hello world-size project is pretty ridiculous, don't
> you think?

dev-util/cmake-2.6.3: 429 files, 25 non-files, 24923.813 KB

Absolutely.

In response to: cmake vs autotools, a benchmark

Luca Barbato [Member] — Tue, 14 Apr 2009 06:43:42 +0000

illogic-al

- libtool is a tool made to hide away gory details certain systems had, pkgconfig nowadays solve most of the problems in a nicer way indeed. Still I wonder why you had to fiddle with .la files...

- I have looked at cmake the first time kde4 started using it and my eye bleeded. the syntax was horrible. I looked it again now and the syntax got at least nicer but still it isn't any better than autoconf + automake.

- For a bare autotools project you have 2 files, Makefile.am and configure.ac I please you to take your time and check the new documentation about autoconf or look at the Diego's articles about it.

In response to: cmake vs autotools, a benchmark

Luca Barbato [Member] — Tue, 14 Apr 2009 06:33:46 +0000

Benjamin
1) cmake is easy to deploy.

last time I checked it depends on:
net-misc/curl
dev-libs/expat
dev-libs/libxml2
dev-libs/xmlrpc-c
a C++ compiler

I do not chain back deps, I'll let you do this exercise by yourself

autoconf
>=sys-apps/texinfo-4.3
>=sys-devel/m4-1.4.6
dev-lang/perl

automake
sys-devel/autoconf

libtool
sys-devel/autoconf
sys-devel/automake

implicitly bash and a proper C compiler also.

sooo basically... perl and bash.

now, on windows maybe the deps are different, maybe you just install the executable (as you can do by using cygwin or msys as well)

2) cmake is a lot easier to learn.
Probably is better documented, and more people is giving you better examples for start. Autotools main fault is the fact since few years ago the documentation was quite poor and scattered, add to it the fact nobody is stopping you to abuse bash or make instead of using the features already provided and you see why people perceive autotools (automake in particular) that bad.

3) Why learning several if learning one suits?
I like to have a toolbox, not a single big hammer. You see the tendency to have domain specific languages to solve better different issues. In this case makes little difference taking a some small single domain languages and lump them together probably.

4) cross platform support.
You cannot claim it is better than the autotools one

Looks like it again cmake strong point is windows. Everybody loves windows.

In response to: cmake vs autotools, a benchmark

Maciej Mrozowski [Visitor] — Tue, 14 Apr 2009 02:28:42 +0000

Find${PKG}.cmake modules bundled with cmake are mentioned (in Documentation) to be simple and "quickstart", rather than reliable robust solutions for production - so your argument is quite invalid here, Diego.
What's the most important in CMake - it's much harder to write bad cmake script rather than bad autotools/automake/libtool script.
While packaging KDE4 for Gentoo (it will be two releases now, and live KDE releases in overlay for a couple of months), I've seen enough to state that CMake is in any way better to get things done. If autotools are that great, easy and all, then why don't we see yet mysql and openldap split ebuilds in tree?
Why does it take weeks to covert libmysqld from static to shared library?
Why X11 team is currently fighting with xcb ABI change consequences caused by broken by design libtool files? (.la)
And why KDE Gentoo team can easily split/merge packages in any possible way anytime?
And why we can fix or workaround most buildsystem issues in a few minutes without exchanging unnecessary emails?
Autotools are just an old relic kept for backward compatibility and should die as soon as possible.
Also having over 500KiB of buildsystem scripts for simple hello world-size project is pretty ridiculous, don't you think?

In response to: cmake vs autotools, a benchmark

illogic-al [Visitor] — Sun, 12 Apr 2009 12:53:43 +0000

As for cross-compiling, I'd just point you to all the non-ruby modules.

P.S. as this is free software should you have a problem, you could a) fix it, or b) report the problem.
I've seen repeatedly how the cmake folks are very responsive to either.

"Still I don't see how harder is the autotools set compared to cmake IF it is supposed to give you the same results (dependency tracking/resolution a la make, template language a la m4, running commands a la bash)."
Because you haven't looked.

I'm neither programmer nor build tools guru but have had to mess around with Makefiles, Makefile.ams, Makefile.in and my personal _favorite_ the libtool file. It is orders of magnitude easier to beat a CMakeLists.txt file into submission.

You may point out that the cmakelists file doesn't provide all the functionality of the other, to which I'd reply: "So?"

The point is, with cmake, I've never needed to do anything outside of this file. And if it takes care of everything which autotools does, not forcing me to figure out how it works, then good.

If I'm only compelled to learn about autotools features when they break (and I am) then cmake is automatically better by virtue of the fact that I have never found it necessary to learn their analogues when using cmake.