libtool
[Top][All Lists]
Advanced

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

Re: Recent patch to pass through unrecognized options in CVS HEAD


From: Gary V. Vaughan
Subject: Re: Recent patch to pass through unrecognized options in CVS HEAD
Date: Tue, 14 Sep 2004 18:30:41 +0100
User-agent: Mozilla Thunderbird 0.7 (X11/20040615)

Bob Friesenhahn wrote:
> On Tue, 14 Sep 2004, Albert Chin wrote:
>>> I am keen to come up with a low maintenance framework for tracking
>>> these optioned arguments so that adding new ones is a snap.  Searching
>>> for the right case...esac and adding a new block is a PITA.
>>
>>
>> So you're saying we should not revert the patch? I think that's the
>> most maintainable solution. Libtool has lived without the patch for
>> this long. Adding a case statement to pass through known options will
>> solve the problem of passing through 64-bit flags which should get us
>> better behavior than before. Nirvana, passing through all unknown
>> options, seems impossible.

No, I was recommending that we keep the patches to pass through unknown
options, since that leaves only one problematic case: unknown options with
arguments.  Before the patch *all* unknown options were stopped, and we
would be back in that situation if we revert.

Are _you_ saying you want to keep the patch? Or do you want to revert it
too?

If we keep it, then to follow the path of least resistance, we can then
immediately teach libtool about the options with arguments that we find out
about before the release, with an eye to later refactoring into a generic
mechanism for passing through further unknown options with argument.

The -Wall=off mangling is neither here nor there with respect to this
argument, but seemed like a nice way of providing an interrim mechanism to
force options through if libtool got it wrong...

> I recommend that the patch be reverted.  A generic mechanism can be
> added to specify which options should be passed, and how many arguments
> the option requires.  This may be more difficult to do efficiently from
> a shell script than when using a compiled language.

Shouldn't be too bad now that we are using shell functions, but we need
to normalize the func_mode_* argument parsers before we mess with that
too much.

> In order to ease maintenance, part of the libtool script can be
> automatically generated from an options configuration file.

I was gonna suggest writing an m4 macro to write some code into the libtool
script at configure time...

But first:  Do we revert the patches?  -1 from me, +1 from Bob so far...

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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