[Patch] two patches to compile kdelibs/khtml on windows

[Christian Ehrlicher]

> On Tuesday 06 December 2005 06:56, Christian Ehrlicher wrote:
> > Lubos Lunak schrieb:
> > > Dne pondělí 05 prosinec 2005 21:59 Christian Ehrlicher napsal(a):
> > >>I think this is a good idea but I don't understand why this file
> > >>shouldn't be included into a header ("... put #include <fixx11h.h> in
> > >>the .cpp file (not .h file!) between the place where X11 headers...").
> > >>I have to put fixwinh.h into a header because I get the errors
> there...
> > >>Also I have to include windows.h because of the reason above.
> > >
> > >  The reason is that fixx11h.h alters what's included from previous
> files
> > > and so including it from a .h file could affect files where you don't
> > > expect this. And from looking at your patch I don't see why DOM
> headers
> > > should include platform-specific .h files, you should include
> > > platform-specific headers in platform-specific .cpp files.
> > >
> > >  That said, since fixx11h.h says it should be without side effects,
> > > including such files from headers shouldn't be probably a problem if
> you
> > > really have a good reason to do so.
> >
> > Here the fixwinh.h and a patch to include it in the three headers where
> > I get compile errors. It should not affect compilation on linux.
> 
>  So it really needs to be used in the headers?
What else should I do? The headers redefine those values and I can't include
fixwinh.h everywhere the headers are included. And if they are public
headers nobody knows that they have to include fixwinh.h first...
Is fixx11h.h actually installed so it can be use outside kdelibs?
> To give you a slightly
> better 
> idea why I have written in the instructions to include it in .cpp files, 
> consider this:
> a.cpp:
> #define RELATIVE // for debugging, give me relative times
> #include "rendering/render_style.h"
> // no X11 or windows headers here at all
> ...
> #ifdef RELATIVE
> ... some debug code here
Yes, that's clear, but you can also get problems without fixwinh.h because
render_style.h redefines RELATIVE and (if you don't get a compiler error in
the header) '#ifdef RELATIVE' is true every time.
> 
> > // OPTIONAL is defined '#define OPTIONAL' - so what to do here?
> 
>  If you don't expect this empty #define will be used anywhere just #undef
> it, 
> otherwise remap it to #define WOPTIONAL (note that even though your
> comments 
> say to use W* the code uses X*).
thx - will fix this

I wonder if the first idea simply undefine the four defines in the
respective headers isn't the better one...


Christian

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++