Status of libtool 2.2.X?

[Kevin Kofler]

Ralf Corsepius wrote:
> See, all FUD, you simply are spraying hatred against something you don't
> understand or don't want to understand.

Your reply is the FUD. ;-)

> To me, cmake is
> * not easier to learn, just different

Probably because you already learned the autotools, so you don't notice its
learning curve anymore. Or you just haven't really tried CMake yet and so
don't know how easy it is to get things done in it.

The fact is, the autotools are a PITA to really understand. Things like:
* when what file needs regenerating and/or gets automatically regenerated
during make and why,
* m4's arcane syntax, including considerations like when to quote things
where, but also just the syntax itself (dnl for comments, [] for quoting
etc.)
and some other stuff work like black magic. (The first issue is also why
the "autoreconf" sledgehammer, which got frowned upon earlier in this
thread by some libtool developer(s), exists.)

Then there's also the fact that there are too many tools: with CMake, you
write all the definitions in one language/syntax, and it's up to you
whether you want it all in one CMakeLists.txt or in several (e.g. one per
directory, you can also have Find*.cmake files for library detection code,
though those usually ought to be provided centrally, and finally you can
also include any arbitrarily-named file). With the autotools, you have to
provide at least 2 files (configure.ac and Makefile.am) with completely
different syntax. And configure.ac itself is a mix of shell and m4. You
also have to manually list all the makefiles to generate in configure.ac
even if automake already knows about them, because autoconf doesn't.
(Something I keep forgetting when I add a subdirectory to an
autotools-using project.)

> * non-portable/inflexible.

How is it not portable? It works on all the major platforms and getting it
to work on some obscure *nix system is fairly easy. As for non-*nix
systems, good luck getting the autotools to work on those! They can't even
cope with Window$ without workarounds like MSYS. CMake can be ported to
basically anything which supports C++.

And it's really more flexible than you think.

> * overladden with non-helpful gimmicks like progress percentages and
> color output

You can call color output a "non-helpful gimmick" (though it really helps
visually separating the lines just saying what is being built from any
error or warning messages), but progress percentages are definitely useful!
Do you not want to know how far your build actually is?

> * a crack ridden design (using a central database), reinvention of
> imake, comprising it's design flaws.

It's not crack-ridden, it allows fixing any bugs in a single central place.
It also saves disk space. And if you really need to provide your own
Find*.cmake files, you can. CMake is flexible like that.

I haven't used imake so I don't know how it compares to that.

> * a kde proprietary tool.

Not true. CMake has been developed by Kitware for use in other projects, it
got adopted by KDE only later. It has not been developed specifically for
KDE. And several non-KDE projects are also switching to it. CMake is not
KDE-specific.

And no, it's not proprietary in the sense of "proprietary software" either,
but I think you know that already. ;-)

        Kevin Kofler