Arguments against including libtool with gnucash source?

[Dave Peticolas]

--=-oDTdvJ4uoc1lvslhf3IY
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2001-11-04 at 08:57, Bill Gribble wrote:
> The libtool documentation recommends including the libtool macro files
> and ltmain.sh in the distributed source of applications.  The 'libtool'
> script is generated by configure, but it is built from the components
> shipped with the source rather than ones provided by the system it's
> being built on. We don't currently do this, relying on 'libtoolize
> --force' being run during the autogen step of gnucash configuration to
> provide an ltmain.sh from the installed version of the libtool package
> on the user's system.=20

Just to clarify, we do ship the libtool macros with 'make dist'
sources, we just don't put them in CVS, since they are generated
by autogen.sh.


> This has been OK up till now, but the Makefile hacks needed to support
> libtool-1.3.4 (what's installed on almost all Red Hat systems) are ugly
> and depend on undocumented libtool behavior. =20
>=20
> Why don't we include ltmain.sh generated by libtool-1.4.2 in the gnucash
> CVS tree, and simplify our Makefile.am files by using the libtool-1.4=20
> syntax rather than the 1.3.4 hack?=20

But will the ltmain.sh create libraries that can be opened by
libtool 1.3.4? And will this mean libtool 1.3.4 users will now
be subjected to the extremely large link times of libtool 1.4?

dave


--=-oDTdvJ4uoc1lvslhf3IY
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA75dfL5effKKCmfpIRAvDBAJ0WggxxpaqiNHewWSiKD7uGe0PwmgCfSjpV
xDcH+7zdabpHpSITV67B1Yg=
=UaK0
-----END PGP SIGNATURE-----

--=-oDTdvJ4uoc1lvslhf3IY--