[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cygwin] cwrapper emits wrapper script
From: |
Noah Misch |
Subject: |
Re: [cygwin] cwrapper emits wrapper script |
Date: |
Sun, 3 Jun 2007 20:02:03 -0700 |
User-agent: |
Mutt/1.5.9i |
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.