On Wed, Jul 02, 2008 at 09:36:25AM -0400, Bill Hoffman wrote: >Christopher Faylor wrote: >>On Mon, Jun 30, 2008 at 06:27:29PM -0700, Kelly O'Hair wrote: >>>Thanks. And I understand the "no guarantee" issue, we ran into a >>>problem with find.exe too a while back. >>> >>>I also understand their point of view on these paths being problematic, >>>but unfortunately the OpenJDK build process uses such a mixed bag of >>>tools (misc unix utils, java.exe, cl.exe, rc.exe, rebase.exe, etc.) >>>it's tricky to sort out when to use what kind of pathname. >>If the build process uses a mixed bag of tools which take different >>types of path specifications, you sort of get what you pay for. That >>sounds like something that needs to be fixed. If there is no real >>desire for the build process to be UNIX-compatible then maybe it should >>be using pure MinGW tools and eschewing Cygwin altogether. It's hard >>to see why Cygwin tools would be a benefit in this case. >Not to rehash an old argument, but Cygwin actually provides the best >gmake environment for the visual studio compiler. The main benefit for >using gmake with the visual studio compiler is to be able to use -j N. >With dual and quad core processors very common, the pay off from >parallel builds is worth it. If you run a native windows gmake, it >does not run the job server so -j options are not correctly handled for >recursive make calls, and it is not so useful. Msys sounds like a good >option, but last time I tried it, it did some odd stuff with command >line options that start with /. It converts them to paths. So, if you >have cl /DFOO=bar, you get cl c:/DFOO=bar as a command line. If you >use the MinGW gmake, you have the job server issue and -j N does not >work with recursive make. However, the cygwin gmake works very well >with visual studio windows paths and forward slash command line >options, and -j N.
If there is a mingw jobserver issue, it sounds like a bug. Has it been filed? Despite Cygwin being good at what it does, that doesn't mean that it will lose its core focus of providing a UNIX-like environment on Windows and guarantee a seamless experience if you are using MS-DOS paths. A utility may understand c:\ paths but there are no guarantees. The current version of Cygwin make is an example of this. cgf _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32