Re: [cygwin] cwrapper emits wrapper script

[Noah Misch]

On Sat, Jun 02, 2007 at 10:56:22AM -0400, Charles Wilson wrote:
> Noah Misch wrote:
> >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?

Correct.  I was not proposing any change to the user interface for running an
executable linked to uninstalled libraries.  Certain changes to the internal
interfaces/implementation might improve code quality.  In any case, those
concerns need not block your patch.

> 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.  

Agreed.

> ... 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.

Unix can afford an extra fork.  You may be right that consistency in this area
provides little value.

> >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.

I forgot that Libtool can source the wrapper script.  Ignore this idea for now.

> >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.

That is reasonable.

Thanks.