RFR(S): 8022177: Windows/MSYS builds broken

[Volker Simonis]

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 <volker.simonis at gmail.com> 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 <erik.joelsson at oracle.com> 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.
>>>>>
>>>>>
>>>>
>>>
>>