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:
+ WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=no
...
+ 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.
--
Chuck
