Re: make 3.81 and MS-DOS paths (e.g. C: or drive letter paths)

[Bill Hoffman]

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.

-Bill