Re: [9fans] Plan9 development

[Anthony Sorace <a@9srv.net>]

[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]

On Nov 13, 2010, at 21:17, Gary V. Vaughan wrote:

> People like to beat on GNU Libtool, and in some cases that criticism is
> not undeserved... but in my experience, many critics of the tool come
> from a perspective of building on a single architecture.  If you have
> never tried to build and link shared libraries from the same code-base
> on 30 (or even 3) separate incompatible architectures, then you are
> probably missing the point, and needn't read any further.

When I write C code which I intend to be portable, I write against p9p, which gives me roughly a dozen architectures. Before that, I wrote against APE, which does a good job of providing a "least common denominator" posix layer that works with many systems. Simple changes to the mkfile make up most of the difference between platforms. If I cared about some architecture p9p didn't support I'd put the time into p9p; if i really wanted to write posix code, i'd put the time into fixing bugs in the posix libraries.

> AFAICT, without rewriting the entire GNU build system from the ground
> up (and there is far too much momentum behind it to ever gain enough
> traction to switch the GNU eco-system to an entirely new and different
> build system anyway) the following precepts are immutable:

This misses the point, or at least the point here. It may all be true (#5 in particular raises some interesting philosophical questions), but it's #3 that makes clear that we're operating in totally different worlds. libtool may well be the most sensible way of accommodating autoconf/automake - but the most sensible thing to do is *not* to accommodate them.

You may well be right that there's too much momentum behind autoconf/automake to change GNU. But that doesn't mean it's the right thing to do, or something sensible people ought to choose to participate in.

> I'm entirely open to reasoned criticism, and especially to useable
> suggestions on how to improve the design of GNU Libtool.  I probably
> won't pay too much attention if you tell me that I should rewrite the
> entire GNU build system and expect several thousand packages to pay
> any attention to me.  I only maintain GNU Libtool and GNU M4, so my
> scope, and hacking time, is much smaller than that.

Again, we're asking totally different questions. You seem to be saying "what's the best way to make the gnu build system usable?", and libtool may well be a great answer to that question. But it's not the question we ask. If I instead ask "what's the best way to write portable cross-platform code?", autoconf, automake, and libtool don't enter into the discussion.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 201 bytes --]