[Libreoffice] windows.h inclusions (was: Re: Review request for 3-4-2 build fix for Windows)

[Fridrich Strba]

Hello,

On 21/07/11 10:38, Michael Meeks wrote:
> 	Ack'd both fixes - much cleaner than this (::std::max)(a,b) type
> ugliness IMHO :-) I'd also love to drop the mdds patch that added those.

I actually dare to contend that the mdds fix is much cleaner and more
robust for following reasons:

1) The MINMAX fix works with our internal boost, but not when we
cross-compile using external boost package. There is a reason why the
boost people, even though they know about this problem did not patch
boost with similar fix.

2) The "bracket" solution tells preprocessor to leave those alone and
that is what one needs exactly in this situation.

3) Whenever you include a modified windows.h in your file, any
subsequent inclusion with different modification has no effect. So, it
is possible that if by chance a windows.h will be in future included in
a file before that boost inclusion, you have the problem back.

4) We have a bit more control over mdds then over boost and since the
problem is solved where it appears, it is not necessary to spend time
trying to track which include sucked the windows.h in.

5) Ugly is in the eyes of the beer-holder.

We had similar problems in libwpd with some of programs using us. Since
we addopted the "bracket" solution, things are smooth.

I could have actually left the boost fix out of the buildfix tagging,
but since all safe fixes at a RC level are dangerous, I preferred to
have tagged exactly the tree I used for our RC2 and that I am 100% sure
that it builds.

Concerning the ucalc.cxx fix, it solves another problem and I added the
MINMAX dance only out of precaution not to cancel the dance done in the
boost header that was to be included immediately afterwards.

The issue here was following: The Win32 api is full of #defines and
unfortunately our vcl and maybe other places use a lot of function
numbers that are identical with function numbers in Win32 API. That is
the reason why we have the prewin.h and postwin.h headers that modify
windows.h before including it by series of #defines and prototype
declarations. Nevertheless, when one includes only one particular little
header from the Win32 api, it is sometimes enough to add a define before
and an undefine after without the whole prewin.h and postwin.h. Which
happens in that file in one header (don't know which one). So, when the
unmodified windows.h is included by boost, some type declarations are
different and you get a clash. That is why I forced the inclusion of a
modified windows.h using the prewin.h/postwin.h hack. It was easier and
more contained then to start to look for which header messes us up.
Especially that changing it somewhere low would mean another day for
Windows rebuild.

Thanks for reading until here

F.