Hi Erik, I've just finished a full build plus an additional incremental build with your enhanced changeset under MSYS witout any problems. The Cygwin control build is still running but I think your add-ons are good so thumbs up!
Thank you and best regards, Volker On Wed, Aug 6, 2014 at 3:28 PM, Volker Simonis <[email protected]> wrote: > Hi Erik, > > thanks for reviewing my change. You're right, there's a problem with > incremental builds. It looks like I've only done full builds to test > the change for the OpenJDK. But for our internal, MSY-only builds, > we've also removed that "/cygdrive" line in NativeCompilation.gmk. > > Thanks for your supplementary fix. I'm just testing it and I'll let > you know once the build finished. > > Regards, > Volker > > On Wed, Aug 6, 2014 at 2:50 PM, Erik Joelsson <[email protected]> > wrote: >> Here is a fix for the incremental build problem, together with Volker's >> original patch. I would suggest we push this in one go. Just need another >> reviewer to take a look at it first. >> >> Volker, please see if this works for you too. For me, if I ran make a second >> time, the build would fail without it. >> >> http://cr.openjdk.java.net/~erikj/8022177/webrev.root.01/ >> >> /Erik >> >> >> On 2014-08-06 12:39, Erik Joelsson wrote: >>> >>> I discovered another problem for msys use in >>> make/common/NativeCompilation.gmk. The logic that rewrites the output from >>> "cl.exe -showIncludes" into makefile dependencies assumes cygwin. This will >>> need fixing to support incremental builds on msys. >>> >>> /Erik >>> >>> On 2014-08-06 11:36, Erik Joelsson wrote: >>>> >>>> I gave msys another shot and managed to get it running on my laptop, even >>>> with mintty so it's not driving me nuts trying to interact with it. With >>>> your patch I managed to get through configure. When building, it seems make >>>> just stops after a bit in langtools however, hogging one full cpu core, at >>>> least at default concurrency setting (which is 4 on my machine). Running >>>> with JOBS=1 seems to work better. >>>> >>>> Are you having the same problems, only being able to build without >>>> concurrency? >>>> >>>> /Erik >>>> >>>> On 2014-08-06 11:01, Erik Joelsson wrote: >>>>> >>>>> Hello Volker, >>>>> >>>>> The changes seem reasonable to me, consider them reviewed. I can make >>>>> the push if you like. >>>>> >>>>> On msys, I would really like to be able to test this myself, but I find >>>>> it hard to get a proper environment setup. Can you point me to a good >>>>> guide >>>>> on what I need to do? >>>>> >>>>> /Erik >>>>> >>>>> On 2014-08-05 20:26, Volker Simonis wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> could somebody please review these straightforward changes which fix >>>>>> the MinGW7MSYS build on Windows: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8022177/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8022177 >>>>>> >>>>>> The details of the change can be found below and in the webrev. I >>>>>> think I need a sponsor for this change because it requires the >>>>>> re-generation of generated-configure files (closed and open). >>>>>> >>>>>> I also want to mention that we at SAP are using the MinGW/MSYS build >>>>>> on Windows since more than a year for all our Java builds (from 4 to >>>>>> 8) on Windows and we're highly committed in keeping this build >>>>>> environment alive. >>>>>> >>>>>> Independently from this change I also have a general question related >>>>>> to the MSYS build: >>>>>> During an MSYS build the Windows command shell is usually called like >>>>>> this: >>>>>> >>>>>> `cmd //c echo $unix_path` >>>>>> >>>>>> As far as I understand, the double slash is needed to prevent MSYS >>>>>> from rewriting '/c' to 'c:/' when calling a non-MSYS executable. But >>>>>> sometimes (notably in BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS in >>>>>> basic_windows.m4) we call the Windows command shell without a quoted >>>>>> forward slash like this: >>>>>> >>>>>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo %~sA" >>>>>> >>>>>> and I don't understand why this works. >>>>>> >>>>>> To complicate things, the MSYS environment contains its own 'cmd' >>>>>> shell script in '/usr/bin/cmd' which only redirects to the >>>>>> corresponding Windows command shell like so: >>>>>> >>>>>> #!/bin/sh >>>>>> "$COMSPEC" "$@" >>>>>> >>>>>> Unfortunately I didn't succeed in unifying all the calls to 'cmd' to a >>>>>> single pattern (i.e. either `cmd //c ...`, or `/usr/bin/cmd /c ...`) >>>>>> which would be desirable, because depending on the actual PATH >>>>>> settings, `cmd` may either call "/usr/bin/cmd" or >>>>>> "C:\Windows\System32\cmd.exe". >>>>>> >>>>>> Can anybody shed some light on this topic (i.e. which "cmd" we want to >>>>>> call and why we have to quote "/c" differently)? >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> >>>>>> 1. common/autoconf/basics.m4 >>>>>> >>>>>> - Check for bsdcpio if cpio is not found. Also make the check for cpio >>>>>> optional, as suggested in the bug report. >>>>>> - Only do the BASIC_CHECK_SRC_PERMS check on Cygwin as it only seems >>>>>> to be relavant there and because the stat utility isn't availabel in >>>>>> MSYS anyway. >>>>>> >>>>>> 2. common/autoconf/basics_windows.m4 >>>>>> >>>>>> - Same story like on Cygwin: '.bat' and '.cmd' files are not always >>>>>> considered executable in MSYS causing which to not find them. >>>>>> >>>>>> 3. common/autoconf/flags.m4 >>>>>> >>>>>> - Use "-WX" option syntax for cl options (instead of "/WX") to prevent >>>>>> option rewriting by MSYS. >>>>>> >>>>>> 4. toolchain_windows.m4 >>>>>> >>>>>> - Account for the fact that the MSYS file utility reports different >>>>>> file types for Windows DLLs than its Cygwin counterpart. >>>>> >>>>> >>>> >>> >>
