On Mon, Dec 23, 2013 at 9:15 AM, bjoern <bjoern.michael...@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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
