Re: [9fans] Plan9 development

["Gary V. Vaughan" <gary@vaughan.pe>]

On 15 Nov 2010, at 08:02, Enrico Weigelt <weigelt@metux.de> wrote:
> * Gary V. Vaughan <gary@gnu.org> 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. 
> 
> 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? 
> 
> 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 
>> of argument; if you were
>> designing GNU Libtool from scratch, how would you do it differently?
> 
> 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

> 
>>  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;
> 
> That's an issue of individual platform backends, which should be 
> 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,
> 
> 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;
> 
> 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?  

> 
Cheers,
-- 
Gary V. Vaughan (gary@gnu.org)