> I think that is oversimplifying things quite a bit. Well, what isn't? Excuse me for writing quick emails without spending a week researching first.
> While there are some > stability issues with cygwin "some" stability issues? > when combined with evil Windows necessities like > in-memory-virusscanners, the slowness is primarily a result of the abysmal > windows filesystem performance. And the slowness of Cygwin's forking and executing the various Perl, shell and whatnot processes involved in each file being compiled (note the pipe to filter-showIncludes.pl) has nothing to do with it? > And the compiling stuff is not really the hard > part when we talk about a windows baseline -- it is stuff like the l10n > tooling, awk, Perl, etc.. If you believe those problems to magically go away > when using the native implementations instead of the cygwin ones, you are very > naive and you would make setting up the build environment even more complex. I hope you aren't talking to me here; of course I am very aware of these issues, and would not recommend even bothering trying. After all, letting them work on "improving the build system" has been a good way to have contributors lose interest in the past... (but for some reason the gbuild attempt was successful, yay!) > The reason why simple compiles on Windows are so slow has nothing to do with > the tooling around it -- it is because we are not using that obnoxious > 'precompiled headers' cheat that makes C++ compilation times on Windows > almost bearable. And this is not oversimplifying? Talking about stuff that doesn't work, and nobody is interested in working on to make work, is fairly Irrelevant, isn't it? --tml _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice