From: "Larry Hall (Cygwin Developers)" <lhall@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: MSYS mode (continue)
Date: Thu, 25 Jul 2013 21:31:00 -0000 [thread overview]
Message-ID: <51F19911.1020705@cygwin.com> (raw)
In-Reply-To: <51F193AF.8020203@gmail.com>
On 7/25/2013 5:07 PM, LRN wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 26.07.2013 00:53, Christopher Faylor wrote:
>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>>>> But underlying there's still a normal Cygwin DLL and
>>>> most tools could just be copied verbatim since they don't need this
>>>> extra functionality.
>>>
>>> And that's the bit where I disagree. Sure, some scripting tools might
>>> not need adjustment, so long as their interpreter was $MSYS-enabled
>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see"
>>> dos-style paths, so its interpreter better be able to handle them.
>>>
>>> But unless you restrict yourself to only passing around relative paths
>>> (or god forbid, that old "unity mount" idea), any .exe will need to live
>>> in one world or the other. Otherwise, how would paths be interpreted?
>>> Using which tools' mount table?
>>>
>>> Naturally from the command line I can compensate:
>>>
>>> msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath
>>> -d /msys/mount/table/path) )
>>>
>>> but yee gods that'd be annoying in any automated setting.
>>
>> I don't know if this helps but the vague plan is to now have two DLLs
>> where before you only had one. You'd still be providing "MSYS" binaries
>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
>> small dll which relied on cygwin1.dll for all of the heavy lifting.
>>
>> You'd still have a normal MSYS distribution and it would still, in theory,
>> support everything (with the possible exception of very lax security) that
>> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll,
>> bash, etc.
>
> Out of curiosity: why do you insist on having MSYS functionality in a
> separate dll, when it could be just part of cygwin1.dll (disableable and
> enableable in the same way other Cygwin features are disabled/enabled -
> via CYGWIN envvar)? What advantage would that give, that justifies the
> increase in implementation complexity (hooking up the dll, etc)? Was
> that justified earlier in this thread and i just neglected to read that
> far back?
Yes, it was mentioned. The idea is to keep the MSYS-specific stuff separate
so Cygwin functionality isn't impacted by what MSYS wants. This reduces
the complexity of the Cygwin code at least.
--
Larry
next prev parent reply other threads:[~2013-07-25 21:31 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) [this message]
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
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=51F19911.1020705@cygwin.com \
--to=lhall@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).