Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.