Arguments against including libtool with gnucash source?

[Derek Atkins]

I think it is probably a good idea (any way you could do this
with intltool/xml-intltool too? ;)  My only concern is how it
would interact with systems that do have a prior version of
libtool.  If the answer is "it will work fine" then I say go
for it.  The fewer dependencies we have the better ;)

-derek

Bill Gribble <grib@linuxdevel.com> writes:

> 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. 
> 
> 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.  
> 
> 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 
> syntax rather than the 1.3.4 hack? 
> 
> For example, this (from the gnome-utils Makefile.am) 
> 
> libgncmod_gnome_utils_la_LIBADD = \
>   -L../gnc-module -L../gnc-module/.libs -lgncmodule \
>   -L../engine -L../engine/.libs -lgncmod-engine \
>   -L../calculation -L../calculation/.libs -lgncmod-calculation \
>   -L../network-utils -L../network-utils/.libs -lgncmod-network-utils \
>   -L../app-utils -L../app-utils/.libs -lgncmod-app-utils \
>   ${GNOMEUI_LIBS} \
>   ${GNOME_LIBDIR} \
>   ${GNOME_PRINT_LIBS} \
>   ${GTKHTML_LIBS} \
>   ${GLADE_LIBS} \
>   ${GUILE_LIBS} \
>   ${GUPPI_LIBS} \
>   ${GLIB_LIBS}
> 
> would be replaced with this: 
> 
> libgncmod_gnome_utils_la_LIBADD = \
>   ../gnc-module/libgncmodule.la \
>   ../engine/libgncmod-engine.la \
>   ../calculation/libgncmod-calculation.la \
>   ../network-utils/libgncmod-network-utils.la
>   ../app-utils/libgncmod-app-utils.la \
>   ${GNOMEUI_LIBS} \
>   ${GNOME_LIBDIR} \
>   ${GNOME_PRINT_LIBS} \
>   ${GTKHTML_LIBS} \
>   ${GLADE_LIBS} \
>   ${GUILE_LIBS} \
>   ${GUPPI_LIBS} \
>   ${GLIB_LIBS}
> 
> The current version isn't documented or "recommended" by anybody; we
> just tried various combinations of -L and -l to get something that
> compiled on both 1.3.4 and 1.4 systems.  But now we're having strange
> problems with crashes with some ways of using the gnc modules, and it's
> difficult to figure out what's going on when we can't convincingly
> explain how what we're currently doing even works. 
> 
> Changing to libtool-shipped-with-CVS would mean we know what version of
> libtool is being used and we have control over how and when the version
> gets bumped.  Are there any reasons people can think of why this would
> be a bad idea? 
> 
> Thanks,
> b.g.
> 
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available