Re: MSYS mode (continue)

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jul 26 23:06, Charles Wilson wrote:
> On 7/26/2013 4:15 AM, Corinna Vinschen wrote:
> >Here's where I disagree.  I think the executables should *not* rely on
> >MSYS.dll being available.  Ideally the executables are linked against
> >the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
> >So, if MSYS.dll isn't available, they still function as normal Cygwin
> >executables.  That's why I proposed the solution(s) in
> >http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html
> 
> So, in this proposal I'd have an "msys" directory structure, with
> cygwin1.dll, an /etc/fstab, and lots of plain-old-cygwin
> executables, bit-for-bit identical to the executables in my "real"
> cygwin installation/directory structure.
> 
> On executable launch, ALL such applications would check for the hook
> DLL (as directed by an env variable, perhaps, or some other
> mechanism -- maybe encoded in a known-present file,
> like.../etc/fstab? [1])  and if present, load it.

Depends.  If the Cygwin DLL itself cares for loading a side-by-side
MSYS.dll, then yes.  If the crt0.o takes over this job, then only
the applications rebuilt with this crt0.o will do that.

> Now, back in my MSYS-on-cygwin installation, there are SOME
> executables that are actually *different* that the corresponding
> ones in real-cygwin-land.  Stuff like make, bash, perl, etc -- all
> may have been compiled with different options because we (the
> mingw/msys people) want them to behave differently, in ways that
> can't automatically be handled by the hooked changes in
> cygwin1.dll's own behavior.
> 
> Have I got that all correct?

More or less, yes, except for the tiny detail above.

> [1] I think this is better than an environment var, because then my
> "regular" cygwin tree and my "msys" cygwin tree would both just
> work, without needed extraneous global env vars that might interfere
> with the other's operation.
> 
> In fact, I might want *different* CYGWIN env var settings for the
> two trees, but unless I set them in the global env then
> StartMenu-launched apps lose out.

They don't lose if you do it right.  Don't start the application,
start a script or batch file instead.

> Could we maybe extend the CYGWIN env var idea to files, similar to
> the /etc/fstab[.d] structure, which are then *augmented* by $CYGWIN?

Reluctantly so.  Opening files costs time.  Reading the env is extremly
cheap in comparison.

> >Another alternative would be if the Cygwin DLL itself had a switch to
> >load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
> >even with completely unchanged executables.
> 
> Right -- but *some* executables would need to actually BE different,
> aside from the underlying posix library's behavioral changes, to get
> a "real" MSYS environment.

Yes, that's what I said all the time.  MSYSies will want another make
and maybe another bash.

> The MSYS team would just provide patched and (re)compiled versions
> of most of their current set of tools...and if users wanted to "drop
> in" (e.g.) git.exe, well they are welcome to try it.  No support
> offered or guaranteed, and they might just get lucky.

Yes.  I'm sure this works most of the time and only a couple of tools
really need to be cripp^Waugmented.

> As cgf pointed out, if "we" (cygwin) are trying to come up with an
> easy upgrade path for existing users of MSYS, then we (mingw/msys)
> users would prefer not to have to change our existing fstab format
> on all of our installations.  Unless you (we, cygwin) automate that
> somehow...

I think the latter should be a "we, msys".  Providing an upgrade
script from MSYS to MSYS2 doesn't look like a Cygwin task to me.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat