This is the mail archive of the
mailing list for the Cygwin project.
Re: Adding MSYS functionality to Cygwin
- From: Warren Young <warren at etr-usa dot com>
- To: Cygwin-L <cygwin at cygwin dot com>
- Date: Tue, 18 Jun 2013 16:04:06 -0600
- Subject: Re: Adding MSYS functionality to Cygwin
- References: <CABEPuQJDLjtbcLig1isTUJgb6RBCD8LNShbm9mTPcb9WM5S5fw at mail dot gmail dot com> <51C0B08E dot 8080900 at etr-usa dot com> <CABEPuQJJpRfPKSwZ7M0eTOdp1HxDcmvuy1=qXFHBw-8kLkZ1ZQ at mail dot gmail dot com>
On 6/18/2013 13:30, Алексей Павлов wrote:
2013/6/18 Warren Young <email@example.com>:
On 6/18/2013 12:40, Алексей Павлов wrote:
1. The correct definition of executables belonging to Cygwin DLL.
Can you give an example of what you mean here?
All cygwin applications depends on cygwin1.dll. We need to translate
arguments only for non-cygwin applications.
It would be possible, though somewhat evil, for Cygwin's exec()
implementation to peek at the DLL dependency list of a program before
starting it, and from that infer whether it should automatically
The I/O hit this would cause would be nontrivial. Keep in mind that one
of the core ideas behind Unix is that fork() is cheap, and exec() is
even cheaper. This deeply affects how software native to Unixy systems
gets designed. As a result, Cygwin already has a problem with its slow
fork() implementation; this idea makes exec() expensive, too, with
predictable consequences to overall system speed.
I don't see how Cygwin couldn't afford to behave this way by default.
Maybe as an option?
2. Translating paths in arguments and environment variables to Windows
I just re-read this, and realized the implications of "and environment
variables." You're proposing some kind of global search-and-replace
operation, which will inevitably turn into a Whac-a-Mole game.
From my explanation above, you do see how expensive it would be for
Cygwin to implement your desired behavior, right?
Also when you using autoconf utilities generated Makefile has Cygwin
paths and you cannot use it with native compiler.
Those on the Automake list have wrestled with this off and on. It's
more or less impossible to solve, which is why competing systems like
CMake, SCons and Bakefile were created.
I think the best you can hope for is that if you run ./configure under
Cygwin with CC=i686-pc-mingw32-gcc and such, it creates a Makefile that
works with Cygwin make, which calls out to the MinGW cross-compiler.
Since the cross-compiler is a Cygwin app, not a native executable, it
understands POSIX paths yet still builds native Windows executables.
Or, you could say "./configure CC=mingw32-gcc" and depend on my proposed
answer to your point #1.
4. Ability to change OSNAME that controlled by uname function in Cygwin
Who needs this, and why?
To use with native mingw compilers. We change OS to MINGW32 and
autoconf utilities think that it is Mingw shell.
What's wrong with using the MinGW cross-compiler from the Cygwin package
5. Use shorted mount point options in /etc/fstab - only win32_path and
Why do you need this?
For backward compatibility with old MSYS and users experience of using MSYS.
I don't see why that's Cygwin's concern.
It should be sufficient for Cygwin to provides a reasonable path
forward, so that those relying on MSYS can migrate to the new scheme.
Infinite backwards compatibility is its own problem.
Doesn't it conflict with your point #3? A portable Cygwin would go out of
its way to avoid using /etc/fstab. I would guess that such a Cygwin variant
would simply provide an unchangeable default behavior, and you'd have to be
happy with it.
No it doesn't conflict. Sometimes you need mount points. File
/etc/fstab doesn't break any portability option)
If you need custom mount points and such, use Cygwin.
For Win32 applications we cannot use Cygwin symlinks - only native.
But native symlinks sometimes can't be used - you haven't privileges
for it, filesystem doesn't support it.
I already know that. Your proposal is wrong-headed from the start. If
you repeat it, it's still incorrect.
Here's something for you to try on your own system:
$ cd /bin
$ mv ln.exe sane-ln.exe
$ ln -s cp.exe ln.exe
Or if you're feeling really ambitious, do it at the cygwin1.dll level,
by changing its implementations of link(2) and symlink(2) to recursive
copy operations. You have the source.
If the resulting system works well at all, it will be much slower. I
predict you'll find that something breaks, though, due to the semantic
issues I tried to show by example in my previous post.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple