libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HEAD: workaround for released autotools


From: Ralf Wildenhues
Subject: Re: HEAD: workaround for released autotools
Date: Sun, 28 Aug 2005 21:26:28 +0200
User-agent: Mutt/1.5.9i

Hi Gary,

* Gary V. Vaughan wrote on Sun, Aug 28, 2005 at 06:30:12PM CEST:
> On 27 Aug 2005, at 19:56, Ralf Wildenhues wrote:
> >This is an ugly (from a stylistic point of view) patch to make CVS
> >HEAD Libtool work with Autoconf 2.59 and Automake 1.9.5, which lack
> >features in their support for AC_CONFIG_LIBOBJ_DIR: just symlink the
> >libobj source files into $top_srcdir from bootstrap, and distribute
> >them.
> 
> In principle, that's fine.  The attached runs a test during bootstrap
> to decide whether the workaround is necessary.  This simply means that
> if the person who bootstraps a release uses a new enough (or suitably
> patched) autotoolset then the extra copies aren't added to the dist
> tarball.

Why, oh why wait another minute for bootstrap to finish?  It's not like
this would be the first work-around for limitations in Automake 2.59.
Besides, your patch adds about as much size to tarball as the duplicate
files do.

> >I can add a note to HACKING about this if you like.
> 
> No need.  I think this version being self correcting as the installed
> tools are upgraded is sufficient.

Hmm.  I know more than one system where a plain "configure" without
options will not lead to a working compiler configuration.  No, not
everyone has config.site's employed.  I for one don't.

> >OK to apply?
> 
> I prefer the attached... ;-)
> 
> Tested with stock 1.9.6/2.59, darwin & subdir-libobj patched  
> 1.9.6/2.5.9, and bootstrapping with one and `make dist' with the other
> set in both  directions.

Have you tested with CVS version of one, and released of the other?

Note to the actual patch: you need to quote uses of $testdir.  And you
scribble around in the source tree should ${TMPDIR-/tmp} be full.

It'd been easier to leverage AS_VERSION_COMPARE, but that wouldn't have
worked on Solaris till last week, either.

Honestly, I think this is bloat.  All 2.59/1.9.6-induced workarounds are
trivially found by a single grep.  If on the other hand another item is
found that needs addition to M4SH_INIT, we have to maintain several
copies yet again.

Regards,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]