RFD: automake, autoconf and libtool

[Ade Lovett]

Well, I've been bouncing my head (on and off) against an interesting 
brick-wall known as automake/autoconf/libtool.  I've got a few 
patchsets knocking around, which break the tree in various weird and 
wonderful ways, so I'm soliciting comments.

So far, the various ports now install versioned binaries in the $PATH 
(eg: automake14, autoconf253, libtool15) so that 'normal' programs 
don't get confused by a (possibly incorrect version) 'libtool' (for 
example).

The USE_AUTOMAKE/AUTOCONF/LIBTOOL variables have been modified to 
accept not only 'yes' (for the "system default"), but also a specific 
version number if required, negating the need for three other USE_* 
variables (USE_foo_VER) -- with the rapid increase in the number of 
USE_* variables, this is probably a Good Thing[tm].

Using these knobs also turns on a bunch of other stuff, including 
adding 'hidden' paths so that programs can execute 'libtool' and get 
the right one (at least at compile time).  They also turn on various 
configure steps which are not required for some ports - rather, they 
need either a build- or run-time (or both) dependency on, say, 
'automake' - the USE_* knobs in place don't take into account either of 
these situations.

So, we're faced with a few problems (which apply not only to the triad 
of tools mentioned here, but also are more far-ranging):

   how to provide the capability for multiple versions of the same port 
to be installed at the same time
	   - ensure no overlap between versions, so one doesn't overwrite 
another
	   - provide mechanisms for another port to depend on a specific 
version, either at a build-time, run-time, or both
	   - optionally provide extra mechanisms to affect how a port is 
built, according to various knobs
	   - provide an easy means to detect when a port (or, harder, at 
run-time as a package), accesses a non-versioned
	     tool, and point it in the right direction.

The first two are essentially done, though can be reworked at will (and 
almost certainly will be as part of a bigger
future COMPONENTS project), the third is a simple matter of adding 
extra knobs (on by default to preserve POLA) to do the configure time 
hacking, the fourth, to coin a phrase, is going to be a pain, though 
there are a couple of wrappers out there which look for specifics in 
order to determine the appropriate version (see, eg, cygwin and gentoo 
linux)

Comments welcome.

-aDe