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)


2013/7/30 Corinna Vinschen:
> 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.
>
We need to determine places where you need to create hooks in
Cygwin.dll and also prototypes for external functions (input and
output arguments). Msys mode only change functions for non-Cygwin
applications and in this case where it can be handled? In cygwin.dll
or in msys.dll?
For example, when we pass arguments to new process we determine in
Cygwin is new process depends on cygwin.dll or not and make decision
about changing arguments. If new process is non-cygwin then we try to
change arguments else we leave them as is. If we need do implement
decision logic in msys.dll then we need to rewrite many code. But if
we implement it in Cygwin dll then it was simple like this:
if (!iscygexec() && msysmode)
{
  // hook to function from msys.dll
} else {

 // default cygwin code
}

In this case we can create mini-hooks in cygwin DLL that call
functions from msys.dll if necessary.

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