[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Status of libtool 2.2.X?



Patrice Dumas wrote:
On Thu, Dec 04, 2008 at 04:03:22PM -0600, Matthew Woehlke wrote:
Patrice Dumas wrote:
Cmake is not  covered by any standard (that I know about).
What's your point? Is the autotools suite "covered by a standard"?

Not at all. But although cmake may not be installed on a POSIX system
all that is required by ./configure should.

I don't mean that cmake is more nor less portable. But vendor cmake may
not be more portable than POSIX tools.

What "vendor CMake"? Right now there is only one CMake (and unlike autotools, it does a fair job of allowing projects using CMake to work with CMake versions other than the one used by the developers). I don't expect to see third-party flavors of CMake (the way you see various vendor versions of e.g. sed, which have no relation to each other besides the degree to which they implement the POSIX spec for such tool).

I can't help but notice that you are ignoring that having CMake provides you with the ability to make changes to the application, where autotools fails miserably at this.

Autotools is theoretically portable to any POSIX system. In reality, since most systems have bugs and idiosyncrasies, porting to a totally new platform is going to involve some work.

CMake is theoretically portable to any system with a C++ compiler.

You mean a specific cmake. But a vendor cmake may be different, with its
own set of idiosyncrasies.

Again, *what* "vendor cmake"? There is no such thing.

Looks like you are not compared the same set
of tools. GNU POSIX utilities don't have specific idiosyncrasies.

Sure they don't. That's why if I write a script for GNU sh (a.k.a. bash) it runs perfectly on every other vendor's shell (and every other version of bash). Likewise for make, sed, awk, etc.

Let's do some score-keeping:

I won't comment on that there are too many things that are not clearly
defined, and, honestly I don't caare. I don't favor cmake or the
autotools. My point is that you are comparing different things.

I think that's the very point I'm trying to make. Autotools has a slight advantage of (debatably) lower build requirements, but very onerous development requirements. CMake, by being a proper build system rather than an ever-changing collective mess that tries to make a build system unnecessary, has a slightly greater minimum cost to build CMake-based software versus the best-case for autotools-based software, but that cost provides an entire spectrum of utility that 'configure' does not, whereas the autotools cost to get comparable functionality is much, much higher.

A fair comparison would be a comparison between, say, GNU POSIX
utilities and standard cmake.

Actually, that's the comparison I /was/ making.

Cost of porting the entire autotools sphagetti bowl: something like a half dozen tools, and good luck getting them to work on non-UNIX-like systems.

Cost of porting CMake: on POSIX platforms, about the same as autotools or better, and unlike autotools, doable for non-UNIX-like platforms.

...and when you're done, I fail to see that autotools provides anything to justify that extra effort. Especially since being able to generate a build system that works without installing anything (the only point I can see as even being worth arguing where autotools is "better") is not guaranteed.

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]