This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MSYS mode (continue)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]