Re: [PATCH] Fix CLASSPATH separator on MinGW.

["Aaron W. LaFramboise" <aaronavay62 at aaronwl dot com>]

Mohan Embar wrote:

> ...but I don't recall the ; / : issue breaking the build. Can you clarify? What
> sort of error message do you get?

MinGW and Cygwin apply a local patch similar to this one that make this
problem go away.  Perhaps you used that?  Its also possible that MinGW
PATH and CLASSPATH handling has changed since then.  See note below.

I don't have the exact error message on hand, but when the libjava build
started, gcj wasn't able to find anything in CLASSPATH, and so the
libjava build failed on the first Java source file.  This is because,
for i686-pc-mingw32, only a semicolon is recognized as a separator, and
so gcj just parses one big, invalid path.  This happens because
PATH_SEPARATOR is set, correctly, to a semicolon on MinGW.

Another way of making this work would be to teach more complicated
DOS-specific path-handling logic to add_path() in jcf-path.c.  This
would probably be conditional on HAVE_DOS_BASED_FILE_SYSTEM.  (I'm not
entirely sure that MinGW still uses this though.  I think there have
been some changes in this department.)

While adding this logic to gcj might be a good thing, for general
compatibility with other targets, I decided against doing it as the
initial fix because, on Windows, semicolon really is the correct
separator to be using, not a colon.  It seems to me that the Makefiles
really should be using a semicolon for MinGW.

> I can't approve this because it touches non-Win32-specific files.
> I don't think the higher-ups will accept this without doing a Linux native
> build and running the libjava and Mauve tests. I can help with this if
> someone else agrees with this approach in principle, but I'm still curious
> as to more details about the "needed to allow the mainline to bootstrap
> on MinGW" part (I assume you mean MSYS).

OK.  I'm not entirely sure that regression testing is necessary;
building should be sufficient, as if this patch broke something, the
build would fail.  If the build doesn't fail, then I don't see how
anything could be wrong on account of this.

I have no problem implementing this in some other way if someone else
feels that something else might be more appropriate.

Actually, I use Cygwin rather than MSYS for building GCC.  MSYS is just
MinGW-specific fork of Cygwin.  I prefer using Cygwin over MSYS because:

1) In the past, MSYS has been plagued with various bugs that would cause
build scripts to fail.  This situation probably has improved by now.
2) Despite this, its my perception that Cygwin is generally more
reliable than MSYS, and probably gets more maintenance attention than MSYS.
3) Cygwin offers a much richer environment.

I put the MinGW tools in front of the Cygwin tools in PATH and supply a
custom Windows ln, and everything works just peachily.

Aaron W. LaFramboise