Re: [cygwin] cwrapper emits wrapper script

[Charles Wilson]

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