On 2010-06-12 01:51-0500 DanKegel wrote:
I've done a number of similar builds ( see http://wiki.winehq.org/UnitTestSuites )
That's an interesting idea, but I would suggest taking it a lot further with WineHq providing the facilities to report testers build efforts rather than having them scattered over the different projects. In particular CMake-based build systems (such as for KDE and many other projects such as PLplot, and CMake itself) have a ctest facility that allows interested users to report nightly test results to a simple dashboard hosted anywhere. So there is a huge amount of potential here with projects with CMake-based build systems to have a central reporting facility at WineHQ that automatically publishes all users nightly build test efforts to the web. There is a big caveat at the moment, however, for this idea. Many/all versions of CMake up to and including the latest, 2.8.1 use a GetShortPathName() / GetLongPathName() trick to get the actual case for a filename, and that generates a hash collision between the names of two CMake language-support files (see http://bugs.winehq.org/show_bug.cgi?id=22286). <aside> I think this was dismissed as CMake just being unlucky in their choice of file names, but an alternative explanation is that the GetShortPathName hash function is poorly implemented within Wine so the probability of collisions is higher than it should be. </aside> CMake has now replaced that trick in their git version by code that does not call GetShortPathName (see http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcbbb7be27f49d3). Until the corresponding patch (located at http://cmake.org/gitweb?p=cmake.git;a=patch;h=018c13ff73d9b7b151cb77f7adcbbb7be27f49d3) becomes part of an official CMake release, you can bootstrap a patched CMake under Wine by renaming the file with the hash collision (which disables Fortran support) so that CMake can build a full patched version of itself (which includes Fortran support). Anyhow, that's the method I am using for my own CMake/MinGW/Wine tests, and why a Wiki cookbook (still being written) is fairly essential for anyone else trying to follow me before the patched version of CMake is released.
and agree Wine is slow at running builds. See in particular http://bugs.winehq.org/show_bug.cgi?id=21423 Please file an enhancement request at http://bugs.winehq.org with your test data, perhaps your bottleneck is different.
Will do. To summarize the situation, you have found file access times are slower on Wine than Windows (and presumably also slower on Wine than Linux). I have found that every simple command I try under wine (such as "cmake --version", "gcc --version", and "mingw32-make --version") all seem to have a large startup latency near 0.25 seconds that cannot be associated with file access times. So I expect both your timing tests and mine for building software under Wine see a combination of the startup latency issue for the thousands of commands that are run in a typical build as well as the file access time issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________
