MSYS mode (continue)
Corinna Vinschen
corinna-cygwin@cygwin.com
Tue Jul 30 09:47:00 GMT 2013
On Jul 30 13:32, Alexey Pavlov wrote:
> 2013/7/30 Corinna Vinschen
> >
> > On Jul 30 04:45, LRN wrote:
> > > On 29.07.2013 19:47, Corinna Vinschen wrote:
> > > > On Jul 29 19:36, LRN wrote:
> > > >> I would expect people to get cygwin/msys in one place, and get MinGW in
> > > >> another. Even mingw-get, while being a source of both msys and mingw
> > > >> packages, clearly distinguishes betweent he two.
> > > >
> > > > That's what I understood differently. From the discussion on mingw-w64
> > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
> > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
> > >
> > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.
> > >
> > > The problem is that the convention that everyone has been following for
> > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
> > > stuff lives in /usr. These two are never mixed.
> > > [...]
> > > So i'd suggest to stick with /usr and /mingw convention and let mingw
> > > take care of itself. It's simpler that way.
> >
> > Fine with me, of course. I don't have that problem myself so whatever
> > works better for you is ok. But then the number of changed packages
> > doesn't really matter. From my POV MSYS sticks to being it's own distro
> > with another focus than the Cygwin distro.
> >
> > So we're back to discussing in how far MSYS can be implemented using a
> > stock Cygwin DLL under the hood and the tweaks being in an external MSYS
> > DLL so users can mix the best of both worlds as they see fit for their
> > purpose.
> >
>
> As I see all discussion not about implementing but about philosophy of
> MSYS.
No. We were talking about how to implement the changes. Your patches
change Cygwin directly, but the idea is to keep the actual changes
separate, outside of Cygwin, as hooks.
> At the start of discussion I wrote about my changes in Cygwin
> sources to have MSYS. And also send small patches but nothing really
> doing in this direction.
> What steps do we need to start any work on implementing it?
> Now I see next points where we can change Cygwin functionality:
> 1. uname function
> 2. reading /etc/fstab
> 3. passing arguments and environment variables to non-Cygwin
> processes ( environ.cc, spawn.cc )
> 4. symlinks changes (copy instead symlink)
Yes, these are the behavioral changes you want to implement, but this is
the discussion as to *how* to implement them. You never actually took
part in this discssion yet.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
More information about the Cygwin-developers
mailing list