On Windows, using abuild to build Java code works fine and should be comparable in performance to building Java code with abuild on a UNIX platform. For C/C++ builds, abuild uses Cygwin for GNU Make and perl. It can use Visual Studio for compilation and can produce targets that don't depend on Cygwin, but abuild itself uses Cygwin. The overhead of running things in Cygwin is very high, and the result is that abuild for C/C++ is slow on Windows even though the Windows compilers are actually quite fast. We need to get abuild working properly with a native GNU Make and remove the last uses of perl from abuild, which means rewriting gen_deps in C++ or otherwise folding it into the abuild sources. The automated test system that is integrated in abuild is likely to stay in perl and likely to continue to require Cygwin, but perhaps that can be rewritten or can be ported to a native perl when a native Windows perl that supports the "|-" form of open is released. Empirical tests suggest that compiling multiple source files at once results in negligible performance improvement. Most of the performance penalty on Windows appears to be spawning processes, particularly when Cygwin is involved. This is true, however, even with Visual Studio's nmake utility and not the result of something about how abuild is implemented.

Although mingw is partially supported and the mingw compiler passes the compiler verification support, mingw support is not really complete in abuild. In particular, we only offer mingw as a valid compiler if the MINGW environment variable is set to 1, and we use gcc -mnocygwin from cygwin to get mingw. This means that absolute Windows paths won't work. Although abuild tries to use relative paths when possible, paths on different drive letters are always given as absolute paths. In spite of these limitations, mingw support should work okay for build environments in which everything is under the same drive letter. If necessary, builds that have to work with both Microsoft Visual C++ and mingw can have conditionals in their build or interface files. Hopefully a future version of abuild will better address this.