[Issue N11069] Questioin about qt cygwin port

[Ralf Habacker]

> > > Mmmh... What is wrong with src/tools/qglobal.h?
> >
> > Because cygwin is mostly linux compatible, we have additional set the
> > Q_OS_LINUX. Additional we have done some work to use win32 api
>
> Cygwin is a POSIX layer over Win32, and all UNIX and Linux systems try
> to be POSIX compatible. So any UNIX system is at least partially Linux
> compatible. This doesn't mean we want to define Q_OS_LINUX on all UNIX
> platforms.
>
> I would prefer not defining Q_OS_LINUX on Cygwin.

Okay, I have looked where this MACRO is used and have added Q_OS_CYGWIN in such
places, so I don't need Q_OS_LINUX.

> > functions
> > inst4ead of the cygwin/unix relevant functions. This is indicated by
> > the
> > Q_OS_CYGWIN_WIN32 macro.
>
> Why use a separate Q_OS_CYGWIN_WIN32 macro? If the Win32 calls are
> really needed I don't mind

Performance reasons.

> Are there really serious performance problems? Can't they be considered
> Cygwin problems that could be fixed in upcoming releases if they are
> reported?
>
Yes, cygwin in general has performance problems with file io, which I have
inspected some month ago, but was unable to fix. :-( It may be that there are
some guys in the future, who are able to fix this, but in the meantime,
especially for kde on cygwin, this patches are necessary to ensure a minimum
performance.

> As I understand it, Cygwin provides a POSIX layer. Combined with an
> X-server, it can run Qt/X11. On the other hand, MinGW does not provide
> a POSIX layer, rather one is supposed to use the Win32 API. This means
> it can't run Qt/X11. Rather Qt/Win should be used with MinGW. Qt/Win
> already has a qdir_win.cpp file, and we may port Qt/Win to MinGW some
> day, but Qt/X11 is not supposed to work with MinGW - by design.
>
Thank you for this info

> So this is really a Qt/X11 over Cygwin issue. If there are performance
> issues with POSIX calls, I see the Win32 calls as hacks to work around
> POSIX layer problems. So it's not that shocking to keep such hacks in
> q*_unix.cpp file.
>
The only problem I see, was that especially the qdir hack makes the qdir_unix.c
file  very difficult to read.
You have seen this patch, is this readable or not ?

> > reserved by the
> > win32 qt release, which isn't free.
> >
> > Any ideas how to deal ?
>
> We use q*_win.cpp files in Qt/Win, as opposed to q*_unix.cpp and
> q*_x11.cpp on UNIX and X11.
>
> Introducing q_*win.cpp files in our Qt/X11 distribution would change and
> break too many things in our internal processes. I can't do that. I'd
> rather keep Cygwin hacks in the q*_unix.cpp files.
>
okay,
>
> > > I can try to apply needed patches, time permitting. If a patch is
> > > more
> > > than a few lines, we'll need you authorization to use them in Qt,
> > > something like:
> > >
> > > 	Permission to use, copy, modify, and distribute this software and
> > > 	its documentation for any purpose and without fee is hereby
> > > 	granted.
> > > 	This software is provided "as is" without express or implied
> > > 	warranty.
> > >
> > >
> > > Actually I don't even have access to a Windows machine with Cygwin right
now

One question: How do you check your patches, if you can't compile ? Is this true
also for the linux-kylix, win32-g++/darwin-g++ ? What kind of reasons does this
have, financial, political or technical.
I'm sure there are solutions, if you want for example with vmware or so :-)

BTW: Currently we are working on the port for qt3.1. If we are ready, I will
send you the remaining patches.

Thanks you for answering

Ralf