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. _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
