This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: MSYS mode (continue)
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Thu, 25 Jul 2013 21:55:17 -0400
- Subject: Re: MSYS mode (continue)
- References: <20130704163612 dot GA4729 at ednor dot casa dot cgf dot cx> <20130705090704 dot GB4009 at calimero dot vinschen dot de> <20130705164230 dot GA7282 at ednor dot casa dot cgf dot cx> <20130711111744 dot GG15346 at calimero dot vinschen dot de> <51F123EB dot 9000900 at cwilson dot fastmail dot fm> <20130725150209 dot GA15619 at calimero dot vinschen dot de> <51F16C82 dot 7030509 at cwilson dot fastmail dot fm> <20130725205320 dot GA2725 at ednor dot casa dot cgf dot cx> <51F193AF dot 8020203 at gmail dot com> <51F19911 dot 1020705 at cygwin dot com>
- Reply-to: cygwin-developers at cygwin dot com
On Thu, Jul 25, 2013 at 05:30:57PM -0400, Larry Hall (Cygwin Developers) wrote:
>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.
Right. Thanks Larry.
The bottom line is that we don't want there to be a bunch of "if
(is_msys)"'s in the code. We don't want to have to worry about how msys
does things. I don't want to have to inspect msys patches, except for
requests for a new hook.
A hook will be a fast no-op in the pure cygwin cases. There would be
very little "implementation complexity".
cgf