RFD: automake, autoconf and libtool

[Joe Marcus Clarke]

On Tue, 2003-09-23 at 00:36, Ade Lovett wrote:
> 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.

I have a few.

First, there is a problem with the multiple libtool ports trying to
coexist.  The .m4 files conflict.  Can we fix it so those files are
installed in their own directory (e.g.
${LOCALBASE}/share/aclocal[13|14|15])?  This will allow IDEs like anjuta
to work properly.

Second, it would be nice to be able to easily use our libtool in every
place.  If we modify USE_LIBTOOL to replace all instances of the local
libtool in ports configure scripts, we can accomplish this.  I think I
sent you a patch for this already.

Third, libtool13 doesn't seem to like the new dynamic root on -CURRENT. 
It tries to run file on /usr/lib/libc.so which doesn't exist anymore. 
Can this be modified?

As for the rest, I think the way the auto* stuff works now seems pretty
cool.  I have used it for a few ports, and it works well for me.  If you
wanted to modify ports to not use the default paths for the GNU tools,
you could use a reinplace like we do with the gnomehack
pseudo-component.  For packages, you'd probably have to modify pkg_add,
but that may be more trouble than it's worth.

Joe

> 
> -aDe
> 
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20030927/9aa0a6a9/attachment.bin