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


On Mon, Dec 23, 2013 at 9:15 AM, bjoern <bjoern.michaelsen@canonical.com> wrote:
There isnt so much we can do about the first thing in a clean way. We can do
something about the second thing, e.g.:

 http://cgit.freedesktop.org/libreoffice/core/commit/?id=66a0713dc9c676182fcd7aa1e21f8dc25c05be5e

btw:
+ else
+ {
+ fprintf(stderr, "no magic for %s(%s) in %s\n", fn, src_relative, work_dir);
+ }
+ }
+ if(!rc)
+ {
+ puts(created_line);  <--  create_line is undefined here if we took
the else above
+ }


- as noted in the comment above the touching of a file in cygwin took some
  ~250ms -- interestingly, this is not CPU-bound. A simplistic approach thus
  would be, to just allways overcommit the build by some factor and see if it
  improves the build time (or the CPU load).

yep. I typically overcommit by at least 50%. for instance on my 8-core
Windows tinderbox I build with -j14
This is especially important as make 'leak' randomly some job-descriptor...


Of course, the real issue is: what is this 250ms idle wait to touch a file from
cygwin about? If we know that we can likely workaround it. Maybe its cygwin
polling some network share for the cygwin->windows path mapping? So any
detective work on that might help:

There is a proposed patch series on gnu make to use
spawn() instead of fork() on cygwin... this has received significant
push-back from cygwin maintainers
as they say that spwan() support on cygwin is flaky since not often used...

- Can one make the delay go away by e.g. disabling network shares/virus
  scanners/other services?

Yes, it has been reported on this ML, some time ago, that disabling
virus scanner for the lo build/source filenamespace is a big win


Finally, Michael Stahl is considering moving gbuild to work on a native windows
GNU make without the cygwin wrapper. But that likely is quite a bit of work.

yep, that would be.. the 'easy' case of building plain cxx could be handled
by generating vxproj file based on what is in gbuild's makefile in a
fairly straight forward fashion
The more involved part is to deal with all the other special case.
That would prolly require developing 'custom build rule' in a vstudio
fashion for all the corner cases
from lex/yacc to idlc, xsltproc  and all the l10n tooling....
A lot of work indeed, on a very despicable platform.. so unless a
Windows fan combined with a skilled dev take that up (and that is a
very rare combo),
it is quite unlikely

Norbert

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.