[Issue N11069] Questioin about qt cygwin port

[kde-cygwin@mail.kde.org]

Hi,

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

Great!


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

I see.

If I get the time to install Cygwin on a Windows machine some day, I'll
maybe see whether Cygwin can be improved. We usually prefer to get
errors fixed in 3rd party tools and libraries instead of adding tons of
workarounds in Qt. Anyway... for now I don't have Cygwin installed.


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

It's not that horrible :-) And anyway, we have no other solution, if we
don't want to change Trolltech internal processes.


> 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

I usually read the documentation and get Qt to build on a given platform
almost without errors (but that's not easy at all with Kylix which is
so different from other UNIX compilers). Then I usually rely on user
feedback to fix run-time issues.

This has worked surprisingly well (Intel C++, KAI C++, Portland Group
C++, Compaq C++ for Linux, Reliant UNIX, SCO OpenServer, SCO UnixWare,
OpenBSD, BSD/OS, AIX 64-bit, HP-UX 64-bit, and IRIX 64-bit support had
been initially implemented this way). By reading the documentation, I
also get a good knowledge of the platform, which proves important for
supporting it.


> does this
> have, financial, political or technical.

It's just there's no commercial interest and resources are limited. I
usually spend my own time on such platforms, except for patches sent to
qt-bugs.


> I'm sure there are solutions, if you want for example with vmware or
> so :-)

Sure, it's just that buying another vmware licence and the commercial
Cygwin version, installing the environment, porting Qt need lots of
resources. Not to mention maintaining the code and providing support...


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

Fine. If possible I would prefer following these steps:

1) Get configure to run. This should already be the case. If not I would
be interested in feedback. Relevant patches would be immediately
applied to Qt 3.1.

2) Get Qt to build. This should almost be the case. I would be
interested in feedback. Relevant patches would be applied to Qt 3.1.

3) Get Qt to run without crashes. This should almost be the case. I
would be interested in feedback. Relevant patches would be applied to
Qt 3.1.

4) Address performance issues. I'd rather apply such patches to Qt 3.2.
I know you won't be happy about that, but that's the best I can offer -
we are trying to follow strict commit policies in the Qt 3.1 branch. Of
course you can still apply the remaining performance fixes to your copy
of Qt.

First this gradual approach will ensure the Qt/X11 port to Cygwin is
sort of "auto-documented" by the successive commits. Then I prefer
introducing Cygwin changes gradually. This will ensure they get better
accepted by other programmers. I'm not sure all of them like the idea
of Qt sources cluttered with code supporting a platform without
commercial interest - but I may be wrong.

Best Regards,
--
Dimitri
Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway