Re: Adding MSYS functionality to Cygwin

[Warren Young <warren at etr-usa dot com>]

On 6/18/2013 13:30, Алексей Павлов wrote:
> 2013/6/18 Warren Young <warren@etr-usa.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 
translate paths.

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.

(http://goo.gl/vpYfA)

>   notepad /home/user/mydoc.txt

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
> > > DLL.
> >
> >
> > 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 
repository instead?

> > > 5. Use shorted mount point options in /etc/fstab - only win32_path and
> > > posix_path.
> >
> >
> > 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
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple