libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 1/6] Add --gnulib-version and --news options to announce-gen.


From: Gary V. Vaughan
Subject: Re: [PATCH 1/6] Add --gnulib-version and --news options to announce-gen.
Date: Thu, 2 Sep 2010 02:49:01 +0700

Hallo Ralf,

On 2 Sep 2010, at 02:05, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Wed, Sep 01, 2010 at 08:09:32AM CEST:
>> On 1 Sep 2010, at 12:25, Ralf Wildenhues wrote:
>>> That didn't help to make it more readable, or cause less buggy code
>>> though.
>> 
>> Well that's because the shared code in getopts.m4sh is still getting
>> exposure.  I think that M4SH_GETOPTS is infinitely more readable and
>> maintainable, and especially worth the effort of using and debugging
>> if I am to contribute a variation to Autoconf's m4sugar libraries.
> 
> I don't think it makes sense to let the users of Libtool, nor its
> developers, be test drivers for proposed features to Autoconf.  The
> testing Autoconf code is best done extensively inside the Autoconf
> testsuite.  For the benefit of avoiding repeated regressions, I have
> added Libtool testsuite exposure to a couple of the issues I found, in
> v2.2.10-70-g21cffd1 and in v2.2.10-73-g3078821.  But fundamentally, I
> think that is not the right approach.

How else would we proceed?  Remember that I had actually been incubating
(and successfully running M4SH_GETOPTS on my machines) for over a year
without incident before submitting to libtool-patches.  Also, I didn't
really intend to push up to Autoconf during that time, and it was only
Eric's interest that gave me the encouragement to think about that.  In
the mean while, M4SH_GETOPTS had already made writing m4sh scripts
noticably faster and more convenient for me, and since I had developed
and tested it in my libtool checkout, contributing it back to libtool
still seems like the obvious step to have taken.

>> Why maintain several copies of the same code if we can do it just
>> once?
> 
> Because the previous code (in ltmain) was not broken?  Because the move
> introduced a few regressions?

Well, libltdl also works well enough.  I'm a good way into a complete
rewrite... are you saying that you'd rather put up with the limitations
of the current libltdl architecture than move to a cleaner and (IMHO)
more maintainable implementation that will no doubt give up several
months of new bugs to shake out? (If "yes" that's not a problem by the
way... I'm using my rewrite in a limited way already, and can publish
it separately in due course as an alternative to incumbent libltdl if
you'd rather).

>>>> Surely you're not suggesting that we continue to hand code, maintain,
>>>> synchronize the option parsing loop in each of our scripts?
>>> 
>>> Well, bootstrap didn't need one so far, did it?

Well, no.  Because it doesn't accept any options, except through the
environment.

>>> How much maintenance
>>> does an option parsing loop need, once it is written?

How much maintenance does any code library need?  Why did we start
using shell functions in libtool rather than letting M4 paste
multiple copies of the same code into ltmain.sh... for that matter
why not just copy and paste the code in-situ over and over, and
only enhance or fix the bugs in the particular copy that reveals
them?

But you know all this. I'm obviously missing your point here, o
we're talking past one another somehow?

>>>   I didn't have the
>>> feeling that that was a biggie on our list before that.
>> 
>> Certainly not a biggie.  But after using the M4SH_GETOPTS generated
>> bootstrap script on my gnulib branch for less than a week, going back
>> to the under-featured master branch version is already painful.
> 
> OK, so which M4SH_GETOPTS-related feature is missing from bootstrap?

--debug, --dry-run, --help, --version, --reconf-dirs, --gnulib-dir and
--verbose.

> Do you propose have a generated bootstrap?

Yes, I posted a v2 of the patch that did just that only a few hours
after the original patch, but the gnu mail servers seem to have lost
it.  I suppose it will arrive in a day or two, but attached again here
FYI.. I've refined it more since then though, so please wait until I
resubmit the full series after the release before reviewing.

Cheers,
-- 
Gary V. Vaughan (address@hidden)

Attachment: [PATCH v2 4_6] Rewrite bootstrap script for consistency with our other shell code..rtf
Description: Text Data

Attachment: PGP.sig
Description: This is a digitally signed message part


reply via email to

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