[ On Wednesday, January 26, 2005 at 17:21:56 (-0500), Todd Vierling wrote: ]
> Subject: Re: safe make replace?
>
> And spent time and resources maintaining these options as OS's and
> toolchains evolved.  If you spent any reasonable amount of time doing
> heterogeneous platform work for a living, you should already know why that
> is a problem.

I have indeed spent at least a good ten years doing software porting and
maintenance professionally -- it's only within the past few years that
I've enjoyed the benefits of working in an almost enirely NetBSD-only
shop.

> These address different concerns.
> 
> Automake is a Makefile abstraction tool that is *also* a policy arbiter.
> Libtool is a compiler abstraction tool, and no more.

Oh, come on now!

Compiler invocation is abstracted in (most) Makefiles and thus Automake,
with the help of Autoconf (or something else equally well suited at the 
is the ideal place to maintain (and select) portable rules to abstract
the compiler and linker invocation portion of any build procedure.

Libtool was originally concieved of and initialy implemented by someone
who was too ignorant and scared of makefiles to do it any other way.  I
really did try to talk him into learning make, but he fell back on the
excuse that the people he was writing libtool for weren't going to be
able to learn make at the same time they had to learn to write and test
library code.  I really do wish I had tried much harder to get the
Automake folks to avoid it too, but that obviously didn't happen.


> No, it manages the compile and link logic more readily than the typical
> developer would have time and resources to do alone.

Well, yes, is sort of does that (but only partly and poorly), but that's
also already done by Automake, and in a much cleaner and more
maintainable fashion.


> Have you tried working with all of AIX, Darwin, and Cygwin on one project?

Yup.  And _many_ more extremely diverse commercial unix-like systems,
most of which no longer exist, thankfully!

Those particular platforms you mention are laughably similar in my
experience.


> More is required on some platforms to get shlibs to work correctly than
> simply twiddling compiler/linker options here and there.

No kidding.  But it still doesn't require the mess that libtool grew into.

I've built and maintained build systems that worked well with BSD(sun)
style shared libraries, some other early hacks on other commercial
unixes, and the old SysV shared libraries, and it don't get much more
diverse than that.  And I did it all without Pmake or GNU Make.

Even the invocation of the original M$-Windows 2.x DLL linking stage was
trivial by comparison (though it sadly required a run-time generated
command file since the argv len is so extremely limited in old MS-DOS
based systems, so there was some necessary duplication of logic and
component lists).

In the end though portable compiler abstraction can all be trivially
abstracted into Makefile macros and rules, especially when one has
something like Automake to hide all the ugliness and duplication under
the hood.


All these issues are really rather silly though when we look back at
where 90% of open-source projects are expected to work and realize that
most are so closely tied to GCC and binutils that it's just not funny
any more.  At that point shoving libtool into the mix is worse than just
a waste of _everyone's_ time.


Of course even automake, and in particular the extent it and the rules
it's designed to follow, goes to the extreme at generating the most
insanely portable makefiles one could ever imagine.  The right solution
is to make minimal demands on build tools, e.g. just as devel/buildtool
does, ane then you only have to worry about a simple script that can
build those things from scratch on a diverse set of platforms.
Unfortunately the Linux world seems to have chosen the GNU Auto* tools
despite the fact that they all live in an almost totally homogenous
world (at this build maintenance level) -- one we couldn't even have
dreampt possible back in the 80s.


-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>