Re: libtool devel works nicely

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>


> Robert Collins wrote:
>
> > Chuck,
> >     lovely wrapper scripts, they work beautifully (its what I used
for
> > libxml2 and libxslt - which I did so I could give you feedback).
>
>
> That's good to hear.  So you exercised the whole
> automake/autoconf/libtool chain?  If so, then how did you put together
>  your -src package for libx*?

Yes, the whole kit and caboodle.
I started with looking in the Makefile.in to see how automake et al were
invoked upstream, then ran
libtoolize -f -c
aclocal
autoheader
autoconf
automake (upstream options) --add-missing.

Then I followed that up with a find -name "*" | grep WIN32 to dig out
all those badly autoconf'd win32 changes. (Some folk just don't get that
autoconf is a feature based toolkit, not a platform toolkit when they
start putting win32 code in place - and libxml+libxslt are _perfect_
examples of how not to do it. [mind you, I've not seen one done
'right' - including those I do myself :}]). So I fixed those up in the
same rough'n'ready fashion (&& !defined(__CYGWIN__)).

Then following a series of build n test n build n test until I thought I
had it right. At that point I picked your script up and started using it
to generate a patch, then to the build and the DESTDIR install (got
bitten by libtool on libxslt with one, the "what library do I link
against when installing to a different DESTDIR?" hard problem - there is
no good portable solution today - so I just solved it for us, it may
generate badly linked libraries on unixy platforms).

> (I ask merely because I'm curious: if you re-auto* a given source
> package, then there are LOTS of changes and your diff is very big.

Try 700-900K :]. I include the regenerated autotool files, because I
don't want end users to have a build dependency on the autotools. If
someone wants to repackage this for a new version, or tweak the source
then they will (obviously) require the autotools.

> Alternatively, you can make minimum changes to high-level files like
> configure.in and Makefile.am -- resulting in a small diff -- and have
> your build script re-bootstrap during the 'prep' phase...but that
> complicates the 'mkpatch' phase. This latter approach is a real
PITA --
> but it's the only way to reliably generate a small patch that can be
> submitted to the upstream maintainers.  NOT that they would accept
such
> a patch if it's generated by a non-regulation libtool or when they're
> not ready to move "up" to the most recent autoconf/automake...sigh)

Well I've got 3 patches in those large .patch files.
There are Cygwin build fixes that are good general solutions. They
affect *.c[c], *.h, *.am, *.in. I've sent in these for libxml2, and will
get them accepted before I do the same for libxslt.
There are Cygwin build fixes that are bandaids to various problems, that
I don't expect the upstream to accept. (i.e. my change the the LIBADD in
libxslt.la dependent libraries and binaries to relink correctly during
install).
Finally there are the autotool crud that makes it pleasant for end
users. This again I have no intention of sending anywhere :}.

Rob