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
_______________________________________________
Make-w32 mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/make-w32
