Hello Tim, all, Your patch addressing fdo#44173 regarding zoom level [1] cause the windows msvc tinderbox failure. [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=022ce7d362f146ed69f54aae20cf2b8c582e9f8d Actually, the one to blame is the msvc library, because it doesn't have round() function. And I have two methods to resolve this: 1. Use ::boost::math::iround. (patch attached) This solution comes from http://stackoverflow.com/a/5849630 This has advantage that it won't fail in any platform, I hope ;-), and it's really "round" the value. But as the round.hpp header isn't delivered yet, we have to modify some boost makefile, then we have to: A. Clean boost (rm -rf $INPATH), then rebuild it. I've tried incremental `build && deliver` but it didn't help. But this led to almost all rebuild in tail_build, IMHO because it triggered the dependency tree, ie boost header is just delivered => rebuild all files which include the boost! I don't think anyone (except tinderbox) love this. :-) OR B. Change the added line into real command (variables substitution) and run it, then `deliver`. Such as: @$(GNUCOPY) -r $(PACKAGE_DIR)$/$(TARFILE_NAME)$/boost$/format $(INCCOM)$/$(PRJNAME) I run it as: ./libo/boost/wntmsci12.pro/ $ cp -r ./misc/build/boost_1_44_0/boost/format ./inc/boost etc. This wouldn't trigger the dependency tree to rebuild. It just delivered only new files. Note: I don't know why we have to "normalize" and deliver just only some part of boost library. Because the rest is unused? This cause the problem when we want to use more library than the delivered ones, as in this case. ;-) Since I discovered the (B.) too late, so I'm in the middle of ~clean tail_build, but a build passed the modified files well ... 2. Instead of round(), take it as ceil() or floor(). This has advantage that you don't need to rebuild. But it won't really "round()". Anyway, I don't think it will cause much difference, except in a very large/small number. Or will we use floor(x+0.5); ? This behaves like round() only for positive numbers, which we don't have negative zoom factor anyway. :-) I don't test this method yet, and I don't know whether we have to #include <math.h> or something. But the linux/mac build passed well (in tinderbox), so maybe we don't need including? Please feel free to comment or correct me if I'm wrong :-) Best Regards, -- Korrawit Pruegsanusak
Attachment:
boost_iround.patch
Description: Binary data