Walking ghost

Posted Sep 7, 2016 8:07 UTC (Wed) by ballombe (subscriber, #9523)
In reply to: Walking ghost by cesarb
Parent article: Contemplating the possible retirement of Apache OpenOffice

> * Be able to, with zero prior notice, produce from scratch in 24 hours or less a fully installable package for all the major architectures (including at least Windows, Mac, and one Linux distribution) and locales (including at least English), from all their currently supported stable branches;

This seems unrealistic, last time I checked building LO took 47 hours and I expect the same for AOO.

Walking ghost

Posted Sep 7, 2016 9:03 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (8 responses)

> This seems unrealistic, last time I checked building LO took 47 hours and I expect the same for AOO.

Looking at recent Fedora build of libreoffice-5.2.1.2-2.fc26:

Started Tue, 06 Sep 2016 14:45:19 UTC
Completed Wed, 07 Sep 2016 06:09:40 UTC

Less than 18 hours.

Walking ghost

Posted Sep 7, 2016 10:34 UTC (Wed) by FLHerne (guest, #105373) [Link] (7 responses)

Fedora have a rather powerful pool of build servers. Apache requires that individual developers test-build each release before signing it off, and no-one's home workstation could compile AOO (or LO) that 'fast'.

Still, I agree with the general point - if you can't *start* a build within 24 hours and be confident in its success, you have a problem.

Walking ghost

Posted Sep 7, 2016 12:30 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

That build time probably the time of the ARM architectures which are much slower. The x86_64 builds took less than 5 hours.

Walking ghost

Posted Sep 7, 2016 12:48 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Yeah, definitely. On my distinctly aged previous-decade 2GHz machines (with fairly fast spinning-rust disks and enough RAM to cache everything) a build takes about three.

Walking ghost

Posted Sep 7, 2016 12:58 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

If AOO does take 47 hours to build, imagine gaining an entire week's worth of time in your build cycle. Insane to think certain people were "build system work is worthless" when so much time could be saved with such work.

Walking ghost

Posted Sep 7, 2016 20:11 UTC (Wed) by Wol (subscriber, #4433) [Link] (3 responses)

> Still, I agree with the general point - if you can't *start* a build within 24 hours and be confident in its success, you have a problem.

:-)

As someone who follows these things on the LO dev list, I agree with the poster who said it takes ages ...

I don't know the details, but iirc the main Windows build machine is an 8-core Opteron monster (it may well have been upgraded by now), and it takes a couple of days to build following a "make clean".

Anyways, the general comments are that Windows takes a LOT longer than nix, and my Athlon X-III (with 16GB ram) takes overnight to do a clean build on gentoo.

Cheers,
Wol

Walking ghost

Posted Sep 7, 2016 20:23 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

You know, using Ninja makes things *way* better on Windows. Is LO using a generator or is it naked makefiles?

Walking ghost

Posted Sep 7, 2016 22:32 UTC (Wed) by shmget (guest, #58347) [Link] (1 responses)

yeah well there has been a lot of work and progress in the past 6 years:
ci build for windows, takes about 27 to 29 minutes.
the ci system is handling build on the 3 platform + a clang + plugin build for all incomming patch in gerrit.. and the slowest build is when the slave that get assigned for mac is one of the mac mini, which can take up to 1h40.
linux build time is much more variable depending on ccache hits rate. it range from 10 to 40 minutes...

a release build for mac, on a mac mini, building with all 100+ localization and signing, take about 3 hours.

between the 2 overlapping branches supported and the rc, the release train averages to one release per week. (these are on top of ci-build)

on top of all that there is also boxes that build what be call 'bibibisect' these build every commit of master and put the resulting binary in a git repo so that qa can do bisection on binaries. These bibisect repo, which we make one per 'epoch', which is about every 6 months worth of commit.. end-up containing 10-12K binary versions of the product for a weight of 8-12GB

even the daily clang+ubsan build takes 'only' about 6-7 hours

Walking ghost

Posted Sep 8, 2016 12:18 UTC (Thu) by Wol (subscriber, #4433) [Link]

Hmmm

So all that cleanup work has been well worth it!!! :-)

Cheers,
Wol