Re: MSYS mode (continue)

[LRN <lrn1986 at gmail dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.07.2013 05:55, Christopher Faylor wrote:
> 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".

OK.

I've attached the patch that alexey gave me recently, if pointless
cygwin->msys renames are removed from msys2, this is what msys2 boils
down to. Please specify how the hooks will look, now that you know which
points of the code need to be hooked up.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR8fTZAAoJEOs4Jb6SI2CwoU0H/1YQSxBz9NisJcCj6wUfo07u
yE7uqieB4sxv3dEJAigBHNVYMbEEqDehY/TVFqMoRIw9SXBSpBWFMla49w8aRHeA
7JUP3+5/cyQYJHXSLBMZBAxdYmSe61PrZVXaH/fMHVuuv31457/He/GaNrM+mos+
q6QqvB2S+lVDIBfZALPyYdS+VZ7jgDVKC2Eb5oFyrEV3EOBnkOFu/PjLUzm1ewMH
X5bn9HHiqHKHUxsss2LBbtZLO75ptLdFPBF+TY83H1TJDHDb3byFGSSGtXhB9+iB
q0j6fhXEqGT+0nCaXangHtt02zx9fvUMLb6bPJ36JTrhv3F/nxEPOjnUtq7Hzm0=
=DGCV
-----END PGP SIGNATURE-----

Attachment: cygwin-msys.patch
Description: Text document