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)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
