From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-8737958" Mime-Version: 1.0 (Apple Message framework v1081) From: "Gary V. Vaughan" In-Reply-To: <20101113192425.GC22589@nibiru.local> Date: Sun, 14 Nov 2010 09:17:46 +0700 Content-Transfer-Encoding: 7bit Message-Id: References: <703b2539-027e-4f9f-a739-00b59f6d3d82@v28g2000vbb.googlegroups.com> <20101113192425.GC22589@nibiru.local> To: weigelt@metux.de, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Plan9 development Topicbox-Message-UUID: 7cddf652-ead6-11e9-9d60-3106f5b1d025 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-8737958 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [[resent from my subscribed email address after the mailing list = rejected the original]] Hi Enrico, On 14 Nov 2010, at 02:24, Enrico Weigelt wrote: > * ron minnich wrote: >=20 >> If you're the kind of guy who can't resist changing things that don't >> need changing, then you won't get it; perhaps you'd be better off >> working on libtool. But Plan 9 is far from dead. >=20 > Nobody with at least half-sane mind voluntarily works on or even > with libtool ... it's basic concepts are fundamentally insane ;-o 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. I'll be the first to admit that the complexity of the shell code inside GNU Libtool is asymptotically approaching unmaintainable... and if I had a lot more hacking time, I'd be spending more of it on untangling the spaghetti. But that is an implementation issue, not a design problem. That said, your comment strikes me as entirely unsubstantiated. Why do you think the concepts themselves are insane? Setting aside the = admitted implementation shortcomings for the sake of argument; if you were designing GNU Libtool from scratch, how would you do it differently? 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: 1. Unix variants (including POSIX layers of non-Unix architectures) build shared libraries in vastly different ways, GNU Libtool needs to handle all of them; 2. Similarly, there are many binary formats that handle run-time loading of code in vastly different ways, all of which must be handled too; 3. There's no use in fighting against GNU Autoconf and GNU Automake, (and, believe me, I hate Perl as much as the next guy), so integration with these is required - Libtool is not a build system it just wants to provide a uniform interface to building and loading dynamic shared objects; 4. GNU Libtool is a system bootstrap tool that is used to build some of the very lowest level components of a Unix installation, so it needs to have the smallest number of runtime dependencies as reasonable possible (GNU M4 is a *build* time dependency, and even that is forced on me by Autoconf). 5. When you link your project code against dependent libraries, you should only have to specify the libraries that you use directly - the indirect libraries should be taken care of by the operating system, and when the OS is deficient, libtool should do the heavy lifting. The current implementation of GNU Libtool also has the following (IMHO desirable) aspects, which are not immutable, but make Libtool easier to use than it would be otherwise: 1. Once installed, it is useable outside the GNU eco-system by any build-system that is prepared to call libtool rather than the C-compiler for building and linking against shared compilation units; 2. It can be used to bootstrap the C compiler (and is used by GNU gcc in that capacity to simplify tracking all the varied options for bootstrapping it's own runtime with the vendor compiler on all the systems it supports). I could probably think of others, but don't want to make this post any longer than it already is. 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. Thanks for reading this far! Cheers, --=20 Gary V. Vaughan (gary@gnu.org) --Apple-Mail-2-8737958 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.10 (Darwin) iEYEARECAAYFAkzfRsoACgkQFRMICSmD1gb1DQCgwMwV402I+ugZvyA9BKMzXNJm b64AmQHU7zWNrE9h13YzisS5H2u5YpDW =jJ7s -----END PGP SIGNATURE----- --Apple-Mail-2-8737958--