From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-21301190" Mime-Version: 1.0 (Apple Message framework v1081) From: Anthony Sorace In-Reply-To: Date: Sun, 14 Nov 2010 00:47:09 -0500 Content-Transfer-Encoding: 7bit Message-Id: <284949CC-81F5-4791-91C1-13357BC23E7D@9srv.net> References: <703b2539-027e-4f9f-a739-00b59f6d3d82@v28g2000vbb.googlegroups.com> <20101113192425.GC22589@nibiru.local> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Plan9 development Topicbox-Message-UUID: 7cfdaf74-ead6-11e9-9d60-3106f5b1d025 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-6-21301190 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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.= --Apple-Mail-6-21301190 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkzfd94ACgkQyrb52b5lrs43nQCfdVbHdGJKbNz6lmuA7l0UZIwG 8pwAnRXhoH4Kd9vJYkAG2oow/gCptmC2 =UBfu -----END PGP SIGNATURE----- --Apple-Mail-6-21301190--