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 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


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