libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)


From: Gary V. Vaughan
Subject: Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 8?)
Date: Mon, 28 Jun 2010 14:23:37 +0700

Hi Chuck,

Thanks for persevering with the Windows support in Libtool.

Regarding our patch review process, I honestly find the tough reviews
valuable in keeping up the quality of my patches, not least because it
makes me more careful not to leave loose ends in my submissions.

Nevertheless, please do remember that it is a *review*, and if you find
yourself disagreeing with something (excepting an outright veto of course),
Ralf and I are both acutely aware that you are the one doing the work on
these patches and the last thing we want to do is retard the progress of
Libtool on Windows, so please don't be afraid to say "on balance, I'd
rather see this patch move Libtool forward in some small way without
addressing issue X right now".  Often, we'll concede in exchange for a
TODO item! :)

On 28 Jun 2010, at 13:10, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
>> On 6/27/2010 4:43 PM, Ralf Wildenhues wrote:
>>> * Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
>>>> I tried to use Gary's _LT_PROG_XSI_REPLACE function, but using a sed
>>>> script to create a sed script and all the quoting nightmares just made
>>>> my head hurt.  So, I have _LT_PROG_FUNCTION_REPLACE that uses the old
>>>> 'copy half the script, emit the new function content, copy the rest of
>>>> the script' algorithm.
>>> 
>>> I don't see this method as the new method of choice.  We already have a
>>> mechanism for years to transport values to the libtool script with
>>> _LT_DECLs and _LT_TAGDECLs, and at least for small code snippets,
>> 
>> Yeah, that's the problem.

I wrote _LT_DECL and _LT_TAGDECL to propagate shell variable declarations to
the libtool script, and I fear it will behave badly if we try to use that
mechanism for shoehorning anything else through, especially because it works
by doing a *lot* of booking-keeping at m4 time.

_LT_PROG_XSI_REPLACE is designed for swapping out fallback implementations
of full functions (suitably decorated) for more efficient implementations
based on the build-time environment.  I think that is exactly what you're
trying to do, but it seems to me like you might be able to work more
effectively in reverse: by putting the full Windows required implementations
into ltmain.m4sh, and using _LT_PROG_XSI_REPLACE to replace them with
stubs when configure is not building on (or for!!) a Windows machine?

(At that point, we should come up with a better name, and changing the
decorator strings to match. The "XSI" is already a misnomer now that I'm
using it for `+=' and ${foo:n:m} constructions.)

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



reply via email to

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