From mboxrd@z Thu Jan 1 00:00:00 1970 References: <703b2539-027e-4f9f-a739-00b59f6d3d82@v28g2000vbb.googlegroups.com> <20101113192425.GC22589@nibiru.local> <79E9F966-3C4E-44D9-8B1F-D22C9548CE74@gnu.org> <20101115010237.GA2116@nibiru.local> Message-Id: From: "Gary V. Vaughan" To: "weigelt@metux.de" , Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <20101115010237.GA2116@nibiru.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 7B500) Date: Mon, 15 Nov 2010 11:17:59 +0700 Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Plan9 development Topicbox-Message-UUID: 7f1bc11a-ead6-11e9-9d60-3106f5b1d025 On 15 Nov 2010, at 08:02, Enrico Weigelt wrote: > * 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.=20 >=20 > Actually, I'm building for lots of different archs almost all the day. > Crosscompiling w/ sysroot, of course. And that's exactly the point > where libtool and other autotools stuff was quite unusable until just > a few years ago (eg. passed *wrong* library pathes to the toolchain). I have been compiling cross-platform Free Software for a living for = about 8 years now, and I have been maintaining GNU Libtool for close to twice = that long. I have never used sysroot in all that time, and no else offered = patches until quite recently. Libtool has been immeasurably useful to me = entirely without that particular feature. At the risk of getting off topic, = that's kind of the point of free software - if it doesn't work quite the way you would = like, fix it! If your fixes make any kind of sense, they'll likely be adopted upstream = for everyone else to enjoy too. >> That said, your comment strikes me as entirely unsubstantiated. Why = do >> you think the concepts themselves are insane?=20 >=20 > The whole idea of libtool essentially being a command line filter > instead of defining an own coherent abstraction interface What is incoherent or unabstract about offering a static-library like = interface to building shared libraries, or an ELF like library versioning scheme? > and one > implementation/configuration instance per target instead of an > autofooled instance per individual package build. How does that scale in the face of a dozen or more OSes, each with at = least a handful of supported library releases and compiler revisions each with = a handful of vendor maintenance patches, each with several hundred API entry-points of which several dozen of each have non-conformances or outright bugs. Worse, many of my clients mix and match gcc with vendor ldd and runtime in various combinations or install and support 3 or more compilers per architecture. Libtool figures out what to do in all of = those thousands of combinations, by probing the environment at build time... = I'd *much* rather wait 90 seconds for each build that try to maintain a = giant tabulation with thousands of entries, which go out of date every time a = new patch or revision of libc or the compiler or the os or the linker comes = along. >> Setting aside the admitted implementation shortcomings for the sake=20= >> of argument; if you were >> designing GNU Libtool from scratch, how would you do it differently? >=20 > See git://pubgit.metux.de/projects/unitool.git Java? For a bootstrapping tool? Does Java even get worthwhile support outside of Windows and Solaris these days? If it works for you, that's great, but I would have an extremely hard sell on my hands if I told my clients they would need to have a working Java runtime on Tru64 Unix before I could provide a zlib build recipe for them :-o >=20 >> 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; >=20 > That's an issue of individual platform backends, which should be=20 > completely transparent to the calling package. Agreed, that's what libtool provides, but to do that it needs to be = intimately familiar with how each combination works. It certainly shouldn't be = trying to do that without calling the vendor compiler and linker. >> 3. There's no use in fighting against GNU Autoconf and GNU Automake, >=20 > Ah, resistance is futile ? ;-o Without user acceptance, that 2 man years of effort I could sink into a = new all singing all dancing build system would be a waste of my time. I'd = much rather spend that time on tools people will get mileage from. >> 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; >=20 > Anyone seriously doing that ? I only see a wide tendency to move away > from libtool in GNU world ... Yep. If I'm porting a cmake package (for example) to the 30 = architectures we support, and shared libraries are required - calling the installed = libtool from the cmake rules is an order of magnitude less work than trying to encode all the different link flags, install and post install rules or = other system specific peculiarities into the compile and link rules in every = build file... And also a lot easier than trying to shoehorn a libtool instance = into the porting source tree. There's a perfectly good working = /usr/local/bin/libtool so why not use that? =20 >=20 Cheers, --=20 Gary V. Vaughan (gary@gnu.org)=