From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: MSYS mode (continue)
Date: Mon, 29 Jul 2013 09:25:00 -0000 [thread overview]
Message-ID: <20130729092513.GA3731@calimero.vinschen.de> (raw)
In-Reply-To: <51F3394A.6050309@cwilson.fastmail.fm>
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
prev parent reply other threads:[~2013-07-29 9:25 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABEPuQ+YxNF6LTAxRTVDQqQsKvGWGuaRxx1JAH62+wZZzgsC9w@mail.gmail.com>
[not found] ` <CABEPuQKRz2kamtrbBF5MjxPiSRMxwJ7NhG6wRrtRXMoBm+quNg@mail.gmail.com>
[not found] ` <20130704091632.GM5118@calimero.vinschen.de>
[not found] ` <CABEPuQKb8ZFvA=5947_JNQ3xZUNi98FTkV=9Q04f8vMY-4q1pg@mail.gmail.com>
[not found] ` <20130704101046.GN5118@calimero.vinschen.de>
[not found] ` <CABEPuQJ2S5jUbJDS+XUhrvdLtu6t53QAvsmQ_q5RbvELZxHJhw@mail.gmail.com>
[not found] ` <20130704103708.GA12995@calimero.vinschen.de>
[not found] ` <CABEPuQ+iF265-SQzfLTmsBegG+BVjpLPowxRAH8ioWv1Us_iYg@mail.gmail.com>
[not found] ` <20130704121617.GC12995@calimero.vinschen.de>
[not found] ` <20130704163612.GA4729@ednor.casa.cgf.cx>
2013-07-05 9:07 ` Corinna Vinschen
2013-07-05 16:42 ` Christopher Faylor
2013-07-11 11:17 ` Corinna Vinschen
2013-07-25 11:06 ` Alexey Pavlov
2013-07-25 11:11 ` Corinna Vinschen
2013-07-25 13:11 ` Charles Wilson
2013-07-25 15:02 ` Corinna Vinschen
2013-07-25 18:21 ` Charles Wilson
2013-07-25 18:33 ` Charles Wilson
2013-07-25 20:53 ` Christopher Faylor
2013-07-25 21:08 ` LRN
2013-07-25 21:31 ` Larry Hall (Cygwin Developers)
2013-07-26 1:55 ` Christopher Faylor
2013-07-26 4:03 ` LRN
2013-07-26 5:46 ` Christopher Faylor
2013-07-26 8:15 ` Corinna Vinschen
2013-07-26 15:14 ` Christopher Faylor
2013-07-26 15:48 ` LRN
2013-07-26 16:16 ` Corinna Vinschen
2013-07-26 16:12 ` Corinna Vinschen
2013-07-26 16:37 ` Christopher Faylor
2013-07-26 16:45 ` Daniel Colascione
2013-07-26 16:47 ` Corinna Vinschen
2013-07-26 17:01 ` Christopher Faylor
2013-07-26 17:03 ` Daniel Colascione
2013-07-26 17:36 ` Christopher Faylor
2013-07-26 23:12 ` Yaakov (Cygwin/X)
2013-07-27 3:07 ` Charles Wilson
2013-07-28 0:18 ` NightStrike
2013-07-29 9:30 ` Corinna Vinschen
2013-07-29 11:00 ` LRN
2013-07-29 11:19 ` Earnie Boyd
2013-07-29 12:20 ` Charles Wilson
2013-07-29 12:49 ` Corinna Vinschen
2013-07-29 14:22 ` Charles Wilson
2013-07-29 18:11 ` Larry Hall (Cygwin Developers)
2013-07-29 11:19 ` Corinna Vinschen
2013-07-29 15:36 ` LRN
2013-07-29 15:47 ` Corinna Vinschen
2013-07-29 16:37 ` Charles Wilson
2013-07-30 1:18 ` LRN
2013-07-30 0:45 ` LRN
2013-07-30 9:04 ` Corinna Vinschen
2013-07-30 9:32 ` Alexey Pavlov
2013-07-30 9:47 ` Corinna Vinschen
2013-07-30 10:27 ` Alexey Pavlov
2013-07-30 10:34 ` Corinna Vinschen
2013-07-30 10:59 ` Alexey Pavlov
2013-07-30 14:55 ` Christopher Faylor
2013-07-30 15:43 ` Christopher Faylor
2013-07-30 16:14 ` Christopher Faylor
2013-07-29 9:25 ` Corinna Vinschen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130729092513.GA3731@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-developers@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).