Date: Mon, 22 Sep 2003 21:36:42 -0700 From: Ade Lovett <ade@FreeBSD.org> To: ports@FreeBSD.org Subject: RFD: automake, autoconf and libtool Message-ID: <87B2B126-ED7F-11D7-8912-000A956B6386@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87B2B126-ED7F-11D7-8912-000A956B6386>