Apache OpenOffice (AOO) Bugzilla – Issue 69671
Instead of spawning cygpath -w, just use Filesys::CygwinPaths::win32path()
Last modified: 2013-08-07 15:26:18 UTC
In a Win32 build using Cygwin, the Perl modules used by make_installer.pl run lots (thousands) of instances of the cygpath program to translate Cygwin paths to the native Win32 paths. Instead, we can simply use the win32path() function from the Filesys::CygwinPaths module. This module is available on CPAN. The latest version is 0.0.4 and it is said to be "experimental", but seems to work fine for me, at least the way I used it in the patch I will attach below. This halved the time required to run a "build" in instsetoo_native (for just openoffice_en-US). It dropped from 22 minutes to 11 minutes for me. I guess it's the "creating ddf files" phase which benefits the most.
Created attachment 39243 [details] Patch to msiglobal.pm
@is: please review the patch
I'm a little bit scared, the package http://search.cpan.org/~somian/Filesys-CygwinPaths-0.04/ is experimental and unchanged since 2003. And, if you're going to implement this change, please update the build requirements with this new dependency. On a different note, wouldn't it be possible to "hash" the first 2 parts of a filename? This should get rid most calls to cygpath/win32path(). For example: /cygdrive/c/bla/... /cygdrive/d/blu/... /tmp/grrr/... /mounted/dir/...
Yes, I agree that the Filesys::CygwinPaths package does seem to be unmaintained. But on the other hand, so is Cygwin itself, more or less ;) It seems to be more or less a question of luck whether one happens to get a good enough Cygwin installation to build OO.o, doesn't it? I have been lucky, and you vq, and so was Radek, but Michael has horrible problems... But anyway, yes, continuing to run cygpath.exe, but only when absolutely needed, should result in more or less the same speedup. A cache for the mappings for the dirnames should work nicely.
> But on the other hand, so is Cygwin itself, more or less ;) It seems to be more > or less a question of luck whether one happens to get a good enough Cygwin > installation to build OO.o, doesn't it? I have been lucky, and you vq, and so > was Radek, but Michael has horrible problems... Well, where is his reproducible testcase? I'm not maintaining cygwin, but the guys (and gal) there do a great job fixing every problem that is reproducible. Since 2003 there were ~20 releases, so using stuff from 2003 might be actually risky. Quote from cygwin ml with respect to fork problems/hangs: > It's crappy coding on the part of the Logitech module. Ross Ridge gives > a convincing argument for what's going on: > <http://sourceforge.net/mailarchive/message.php?msg_id=17999960>. More > info on the loader lock issue is in this paper: > <http://www.microsoft.com/whdc/driver/kernel/DLL_bestprac.mspx>. Now if > only someone could forward these clues to the idiots that wrote that > Logitech crapware, it would save a whole lot of frustration. So, show me one detailed bug decription. (Noone ever cared) P.S.: There is also a fingerprint reader software preinstalled on a lot of Dell stuff that has the same problems as the LogiCrap.
Well, when using Filesys::CygwinPaths you aren't using *binaries* from 2003, that would indeed be slighgly risky. When you install that Perl module using the cpan command, it compiles from sources. It's just a Perl module that interfaces to a couple of calls to the Cygwin DLL. Surely you know that a problem with the hangs are (were, they are gone now for me when using --with-use-shell=bash ;) that they weren't reproducible with any simple test cases, and you don't want to push a whole OO.o build tree ("here's the test case") down the poor Cygwin maintainer's throat, do you?
> Surely you know that a problem with the hangs are (were, they are gone now for > me when using --with-use-shell=bash ;) that they weren't reproducible with any > simple test cases, and you don't want to push a whole OO.o build tree ("here's > the test case") down the poor Cygwin maintainer's throat, do you? I would, but that testcase is not reproducible. I tried to hang the build on several architectures with 2k and XP. It doesn't hang. Not once. Well, debugging would include looking at installed drivers, stopping services, striping the system down until it works, ... You get the idea. Having said that, Filesys::CygwinPaths just links to an cygwin API function cygwin_conv_to_win32_path() <http://cygwin.com/cygwin-api/func-cygwin-conv-to-win32-path.html>. So, if it works and is faster, why not use it.
On a related topic, we could also just use the Win32::Guidgen module to generate UUIDs, instead of running the uuidgen program n+1 times. Unfortunately the Win32::Guidgen package on CPAN is a bit broken, installing it using cpan fails. One has to fetch the tarball, extract it, run perl Makefile.PL, make, make test and make install manually.
So if you as cygwin users want to use the Filesys::CygwinPaths module, please feel free to integrate this into the build environment. But as a new build requirement this has to be documented and the configure scripts have to be adapted. Therefore the target has to be 2.2. -> vq: Can you please take care of this task?
@is: I'll supervise ;) I mean I'll review the patches.
not product version related -> DevTools.
At least in OOF680_m7 msiglobal.pm seems to run cygpath in batch mode now, converting a whole bunch of paths in just one invokation. That is another way to fix this issue, so I'll resolve this then.
On a general note: We shouldn't introduce new CPAN modules for things we can easily achieve otherwise. My guess is that the developer overhead (failing on a new requirement, installing module, reporting bug, creating a check in configure etc) for a new module takes several man days over all OOo developers combined. If the same thing can be achieved with a few hours hacking it might be better to avoid a new dependency. OOo has already a looong dependency list.
Close issue.