[Libreoffice] There is no round() in msvc library (fdo#44173)

Korrawit Pruegsanusak detective.conan.1412 at gmail.com
Sun Jan 15 07:03:33 PST 2012


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boost_iround.patch
Type: application/octet-stream
Size: 7002 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120115/57831401/attachment-0001.obj>


More information about the LibreOffice mailing list