[Top][All Lists]

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

Re: [cygwin] cwrapper emits wrapper script

From: Charles Wilson
Subject: Re: [cygwin] cwrapper emits wrapper script
Date: Sat, 02 Jun 2007 10:56:22 -0400
User-agent: Thunderbird (Windows/20070509)

Noah Misch wrote:
I don't speak for the Libtool maintainers, but I'll throw out my impressions of
the patch, in case it might help move things along.  Not using Cygwin or MSYS
myself these days, I trust that the patch improves things there as you say it
does.  It seems fairly harmless from the perspective of all other platforms.

Thanks for your comments:

Long-term, we can revise this cumbersome division of work between the executable
wrapper and the wrapper script.  Ideally, the wrapper methodology for Unix
should resemble that for Cygwin/MSYS, so we don't have an extra code path
potentially subject to bitrot.  This patch does not introduce those problems,
however, and seems to improve the current situation.

Well, yes, but libtool itself is nothing BUT a twisty maze of extra code paths -- specifically so that end-users can avoid "extra code paths" in their Makefiles and other build support. "We keep track of the complexities so you don't have to", right?

Anyway, I wanted to keep the impact to not-Cygwin/Mingw as small as possible -- zero, hopefully. Anything beyond that is fodder for the next release cycle, definitely not this one. Even so, my changes may or may not be appropriate for 2.0; I'd like to hear from the maintainers on /that/ score...

Long term, at least on cygwin/mingw, it would be /nice/ to do away with the wrapper script entirely -- I'm just not sure that it is /practical/ without a complete redesign of the wrapper system on all platforms <shudder>. The script is used both to launch the target with the right environment settings, but also to pass information between libtool invocations. It's that second bit that's problematic -- and doing THAT bit differently on unix vs. cygwin is more of an "extra code path" than having a simple .exe wrapper IMO. But making all unix do it the cygwin way is not a good idea either: it's slower (extra fork/exec), there's no good reason to make 'em do that except "consistency" (which is not always a virtue), and it's a major change from existing behavior on those platforms.

From a purely Unix-centric standpoint, I would pass the script to a shell via a
pipe, rather than writing it out to a file.  Is that too much for MSYS?

Well, that would require more (risky?) changes in the part of libtool where the wrapper script is "read". Other platforms just source the existing script; I don't know if you can "source" a script on stdin. And if you could, it'd still be doing it some "weird" way on cygwin/mingw ("call wrapper.exe to create a temporary script first, then continue as normal" is slightly weird, but at least it says 'continue as normal' there at the end). Making cygwin even weirder is contrary to your advice about at least /trying/ to keep things unixish and cygwin/mingw similar.

One specific thought:

+  # cygwin/mingw cwrapper will rewrite this line:
+           func_emit_libtool_wrapper_script |
+               $SED -e 's/\([\\"]\)/\\\1/g' \
+                    -e 's/\(WRAPPER_SCRIPT_BELONGS_IN_OBJDIR\)=.*/\1=yes/' \
+ -e 's/^/"/' -e 's/$/\\n"/'

This will be cleaner if you pass the value of WRAPPER_SCRIPT_BELONGS_IN_OBJDIR
as an argument to func_emit_libtool_wrapper_script, rather than hard-coding the
"no" and filtering it after the fact.

That's a thought. I'd prefer to push that change off to a later (small) patch though, rather than rewrite this one again -- especially given the difficulty in regenerating the GCS half of this patch.


reply via email to

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