MSYS mode (continue)

Larry Hall (Cygwin Developers)
Thu Jul 25 21:31:00 GMT 2013

On 7/25/2013 5:07 PM, LRN wrote:
> 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.


More information about the Cygwin-developers mailing list