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

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