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 Jul 30 14:27, Alexey Pavlov wrote:
> 2013/7/30 Corinna Vinschen:
> > 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.
> >
> 
> Now there are not many changes that I do in Cygwin sources and it
> change only small functionality without breaking anything for cygwin
> users (only symlinks is breaking thing).
> If we need to implement changes in external DLL we doesn't want to
> full rewrite modified functions in this DLL. External DLL need only do
> changes inside the Cygwin functions not full replace this functions I
> think.

That was part of cgf's original proposal.  We have the CW_HOOK mechanism
to overload entire functions (per the discussion not fully implemented
yet) but there's no problem to implement a kind of mini-hook with a
set of function pointers called from the CYgwin DLL at certain, yet to
be defined points.

> Maybe you create separate branch in CVS source where we can try to
> implement MSYS mode and also create hook in uname function, for
> example, to try how it work?

That should be possible.

> >From my POV we need to create separate distro for MSYS where in bash
> profile we can activate MSYS mode for Cygwin.dll with some environment
> variable that tell to load msys.dll. But if you want has working
> applications between normal Cygwin and msys-in-cygwin then they need
> to be linked only with cygwin.dll and doesn't need to know anything
> about msys.dll.

Exactly.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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