Status of libtool 2.2.X?

[Matthew Woehlke]

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)