Eivind Eklund
10/1/2004 12:56:00 PM
Let me just state that the main point here is that it is better to
leave the horror of portability to the interpreter level, and avoid
autoconf et al when you've already got Ruby installed anyway.
The below is just information regarding autotools and the fact that
there actually existed a (in many ways better) porting world before
autotools, and hopefully will exist a better world again after them.
On Fri, 1 Oct 2004 01:37:39 +0900, Steven Jenkins
<steven.jenkins@ieee.org> wrote:
> Eivind Eklund wrote:
> > Please let me chime in on the side of cutting the head off autotools.
> >
> > They DO NOT WORK.
>
> This is a little harsh. You may have issues, as I do, with the usability
> of autotools. They may not be right for this application. But they do
> work, and there are literally thousands of packages that attest to it.
The design goal of the autotools was to make porting easier. When, in
practice, for the packages I've had to deal with, porting has been
harder than it was before the introduction of autotools (and at that
point there were more differences to deal with), I feel that I'm
justified in saying that they do not work.
Aredridel wrote:
> The worst part is that they're hard to understand; however, there's
> not much to be done about it and still run on a system with nothing
> but a posix shell and a C compiler.
This is plain incorrect. It was much, much easier to understand
configure scripts etc before the introduction of autotools. The
problem is that sh is a horrible target language for a compiler, and
M4 is a horrible implementation language for a compiler.
Sure, the problem space is icky, but it is not anywhere near as icky
as autotools make it. We had experience with this before autotools,
and that was a trifle harder on the packager, and easier on the person
doing porting - problems were usually fairly straightforward to
resolve.
This changed (IIRC) somewhere in the 1994-1997 timeframe with the
widespread adoption of autoconf.
Eivind.