From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32525 invoked by alias); 29 Jul 2013 09:25:23 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 32377 invoked by uid 89); 29 Jul 2013 09:25:23 -0000 X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 29 Jul 2013 09:25:22 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id B8E1F5200F3; Mon, 29 Jul 2013 11:25:13 +0200 (CEST) Date: Mon, 29 Jul 2013 09:25:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: MSYS mode (continue) Message-ID: <20130729092513.GA3731@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20130704163612.GA4729@ednor.casa.cgf.cx> <20130705090704.GB4009@calimero.vinschen.de> <20130705164230.GA7282@ednor.casa.cgf.cx> <20130711111744.GG15346@calimero.vinschen.de> <51F123EB.9000900@cwilson.fastmail.fm> <20130725150209.GA15619@calimero.vinschen.de> <51F16C82.7030509@cwilson.fastmail.fm> <20130725205320.GA2725@ednor.casa.cgf.cx> <20130726081510.GN5086@calimero.vinschen.de> <51F3394A.6050309@cwilson.fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51F3394A.6050309@cwilson.fastmail.fm> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-07/txt/msg00052.txt.bz2 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