Date: Sat, 27 Sep 2003 02:32:14 -0400 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Ade Lovett <ade@freebsd.org> Cc: ports@freebsd.org Subject: Re: RFD: automake, autoconf and libtool Message-ID: <1064644334.692.18.camel@gyros> In-Reply-To: <87B2B126-ED7F-11D7-8912-000A956B6386@FreeBSD.org> References: <87B2B126-ED7F-11D7-8912-000A956B6386@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-CHnlGvx+YPq9+Q91zQzL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Tue, 2003-09-23 at 00:36, Ade Lovett wrote:
> Well, I've been bouncing my head (on and off) against an interesting=20
> brick-wall known as automake/autoconf/libtool. I've got a few=20
> patchsets knocking around, which break the tree in various weird and=20
> wonderful ways, so I'm soliciting comments.
>=20
> So far, the various ports now install versioned binaries in the $PATH=20
> (eg: automake14, autoconf253, libtool15) so that 'normal' programs=20
> don't get confused by a (possibly incorrect version) 'libtool' (for=20
> example).
>=20
> The USE_AUTOMAKE/AUTOCONF/LIBTOOL variables have been modified to=20
> accept not only 'yes' (for the "system default"), but also a specific=20
> version number if required, negating the need for three other USE_*=20
> variables (USE_foo_VER) -- with the rapid increase in the number of=20
> USE_* variables, this is probably a Good Thing[tm].
>=20
> Using these knobs also turns on a bunch of other stuff, including=20
> adding 'hidden' paths so that programs can execute 'libtool' and get=20
> the right one (at least at compile time). They also turn on various=20
> configure steps which are not required for some ports - rather, they=20
> need either a build- or run-time (or both) dependency on, say,=20
> 'automake' - the USE_* knobs in place don't take into account either of=20
> these situations.
>=20
> So, we're faced with a few problems (which apply not only to the triad=20
> of tools mentioned here, but also are more far-ranging):
>=20
> how to provide the capability for multiple versions of the same port=20
> to be installed at the same time
> - ensure no overlap between versions, so one doesn't overwrite=20
> another
> - provide mechanisms for another port to depend on a specific=20
> version, either at a build-time, run-time, or both
> - optionally provide extra mechanisms to affect how a port is=20
> built, according to various knobs
> - provide an easy means to detect when a port (or, harder, at=20
> run-time as a package), accesses a non-versioned
> tool, and point it in the right direction.
>=20
> The first two are essentially done, though can be reworked at will (and=20
> almost certainly will be as part of a bigger
> future COMPONENTS project), the third is a simple matter of adding=20
> extra knobs (on by default to preserve POLA) to do the configure time=20
> hacking, the fourth, to coin a phrase, is going to be a pain, though=20
> there are a couple of wrappers out there which look for specifics in=20
> order to determine the appropriate version (see, eg, cygwin and gentoo=20
> linux)
>=20
> 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.=20
It tries to run file on /usr/lib/libc.so which doesn't exist anymore.=20
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
>=20
> -aDe
>=20
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
--=20
PGP Key : http://www.marcuscom.com/pgp.asc
--=-CHnlGvx+YPq9+Q91zQzL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQA/dS7ub2iPiv4Uz4cRApT8AJ0f2PbgEtPjUtgTXBdwmozWQo0Z8wCfXfZd
wPsT+0Pca5821ZX218LMI4c=
=tYgu
-----END PGP SIGNATURE-----
--=-CHnlGvx+YPq9+Q91zQzL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1064644334.692.18.camel>