On 19/11/12 19:32, Tor Lillqvist wrote:
evidently local file system (NTFS) is rather slow, and process creation
is very slow (which is important for any make-based build system).
This when seen through the Cygwin POSIX emulation layer, presumably?
yes ... but i don't remember the 4NT/native
yes ... but i don't remember the 4NT/native tools based build system OOo
had back in 2008 or so to be fast by any stretch of the imagination...
Well, I have never used those, so I don't know. Surely those tools,
too, tried to if not emulate, at least simulate, POSIX in some ways?
Anyway, my
On 16/11/12 20:30, Enrico Weigelt wrote:
The real question is - what is the deliverable here ? building on
windows under cygwin is -horribly- slow - if we can use the same
compiler to cross-compile from Linux (as we can) and build around 50x
faster - why would we want to do work
evidently local file system (NTFS) is rather slow, and process creation
is very slow (which is important for any make-based build system).
This when seen through the Cygwin POSIX emulation layer, presumably?
And when using a build mechanism that has been developed on Unix
systems in general and
evidently local file system (NTFS) is rather slow, and process
creation
is very slow (which is important for any make-based build system).
Okay, but this cant explain why cygwin/gcc is so horribly slow
compared to msvc (would make both of them slow).
Does this also mean kicking out
Okay, but this cant explain why cygwin/gcc is so horribly slow
compared to msvc (would make both of them slow).
Cygwin is a POSIX emulation. Some POSIX concepts are *very* different
from Windows. Emulating them takes time and effort.
autoconf alone already is evil enough ;-)
Feel free to
On Thu, Nov 15, 2012 at 11:44:38AM +0100, Enrico Weigelt
enrico.weig...@vnc.biz wrote:
I'd like to setup an win32 build environment which reproduces
the official win32 builds for verifying my patches.
What do I need for that ?
See
Hi Enrico,
On Fri, 2012-11-16 at 11:22 +0100, Enrico Weigelt wrote:
and use the configure options from
distro-configs/LibreOfficeWin32.conf
Thanks.
Is there some specific reason for using MSVC instead of gcc ?
Currently ABI backwards-compatibility for compiled extensions. There
Is there some specific reason for using MSVC instead of gcc ?
Currently ABI backwards-compatibility for compiled extensions.
There are also some features in the code that don't compile with
MinGW. They use API that MinGW does not provide headers for etc.
Let me also point out that we
in addition to above points also there are also open questions around
how we would run unit tests in a MinGW cross-compilation environment
and how well gdb works on Windows; the MSVC C++ debugger is really quite
good.
What about native compiling (not crosscompile) on win32 using gcc ?
cu
Hi,
There are also some features in the code that don't compile with
MinGW. They use API that MinGW does not provide headers for etc.
Ok. Is there already some list of known issues ?
Let me also point out that we definitely do not want to build
*locally* on Windows with GCC (MinGW). MinGW
On Fri, 2012-11-16 at 15:32 +0100, Enrico Weigelt wrote:
in addition to above points also there are also open questions around
how we would run unit tests in a MinGW cross-compilation environment
and how well gdb works on Windows; the MSVC C++ debugger is really quite
good.
What about
Hi,
Anything is possible in LibreOffice :-) having said that -
personally
I'd want to see that adding support for this doesn't tangle the build
system too badly - particularly wrt. confusing our mingw
cross-compilation support.
I have to admit, I haven't tried it yet, but
Hi folks,
I'd like to setup an win32 build environment which reproduces
the official win32 builds for verifying my patches.
What do I need for that ?
thx
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a,
14 matches
Mail list logo
