jextract build fails on windows

[Maurizio Cimadamore]

Thanks. Pushed now.

Apologies for the inconvenience.

I realized that the reason this wasn't caught in testing is that running 
the "jtreg" task doesn't trigger "verify". We probably need a task which 
runs test and does verify.

Maurizio

On 15/04/2022 15:19, Daniel Jarabek wrote:
> Hi,
>
> I have tested and a clean build and verify works correctly on Windows 
> 10 and Arch Linux. Thanks for your help.
>
> -DJ
>
> On 4/15/2022 10:09 AM, Maurizio Cimadamore wrote:
>> See:
>> https://urldefense.com/v3/__https://github.com/openjdk/jextract/pull/24__;!!ACWV5N9M2RV99hQ!Z3N7c7CGYniy3jSpQcJFZ26u1L4RAeY5ztEwnXfrfsHMSREoSRQ3AOQtlHehsP__0s2dJ14$ 
>>
>> Let me know if that works.
>>
>> Maurizio
>>
>> On 15/04/2022 14:49, Maurizio Cimadamore wrote:
>>> Hi,
>>> I can confirm that I see the failure on my Windows virtual machine 
>>> as well...
>>>
>>> ```
>>> > Task :createJextractImage FAILED
>>> Error: no value given for --add-options
>>> Usage: jlink <options> --module-path <modulepath> --add-modules 
>>> <module>[,<module>...]
>>> Use --help for a list of possible options
>>> ```
>>>
>>> Not sure why I didn't see that last time - but I recall there has 
>>> been a last minute change to the build, so it's possible that this 
>>> issue slipped through.
>>>
>>> Maurizio
>>>
>>> On 15/04/2022 14:42, Daniel Jarabek wrote:
>>>> Hi,
>>>>
>>>> Unfortunately even after the PR [1], the build still fails for me 
>>>> on Windows. I did some digging and found what I believe to be the 
>>>> cause. On Windows, argv arguments are parsed for quotes before 
>>>> being passed to the application (in the case of the JVM this 
>>>> parsing is actually implemented in the launcher as far as I can 
>>>> tell, but that shouldn't really be relevant here). My previously 
>>>> proposed fix of adding an escaped backslash to the argument (so it 
>>>> looks like '\\"') seems to be the best option currently. 
>>>> Unfortunately, I was incorrect about this fix not affecting other 
>>>> Operating Systems in my last email. While it builds successfully, 
>>>> when attempting to run the built image it fails with `Unrecognized 
>>>> option: \--enable-native-access=org.openjdk.jextract\`, since the 
>>>> extra back slashes were not consumed by the build process. My new 
>>>> proposed fix it to conditionally add the extra backslashes on 
>>>> Windows, for example by defining an escapedQuote variable based on 
>>>> the current Operating System.
>>>>
>>>> -DJ
>>>>
>>>> [1] - 
>>>> https://urldefense.com/v3/__https://github.com/openjdk/jextract/pull/18__;!!ACWV5N9M2RV99hQ!Z3N7c7CGYniy3jSpQcJFZ26u1L4RAeY5ztEwnXfrfsHMSREoSRQ3AOQtlHehsP__OXbyQJI$ 
>>>>
>>>> On 4/11/2022 2:14 AM, Sundararajan Athijegannathan wrote:
>>>>> Hi,
>>>>>
>>>>> Jorn Vernee reported same issue (and same fix) internally. Not 
>>>>> sure why that double quoting is needed on Windows (perhaps shell 
>>>>> issues).  I think Jorn Vernee will file a PR.
>>>>>
>>>>> Thanks,
>>>>> -Sundar
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>> *From:* jextract-dev <jextract-dev-retn at openjdk.java.net> on 
>>>>> behalf of Daniel Jarabek <jarabekit at gmail.com>
>>>>> *Sent:* 10 April 2022 04:04
>>>>> *To:* jextract-dev at openjdk.java.net <jextract-dev at openjdk.java.net>
>>>>> *Subject:* jextract build fails on windows
>>>>> Hi,
>>>>>
>>>>> After the changes in [1], the jextractapp gradle task fails on 
>>>>> Windows
>>>>> with the error `Error: no value given for --add-options`. While 
>>>>> I'm not
>>>>> exactly sure what is happening here, wrapping the escaped quotes 
>>>>> at [2]
>>>>> in another level of escaping (so they look like `\\\"`) resolves the
>>>>> issue. After this fix, the task still works successfully on linux 
>>>>> (and
>>>>> presumably mac). I would make a pull request to fix this but I am 
>>>>> unsure
>>>>> if this is the best (or even a valid) solution and due to my OCA
>>>>> currently being under review, the merging would be blocked anyways.
>>>>>
>>>>> -DJ
>>>>>
>>>>> [1] - 
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jextract/pull/11__;!!ACWV5N9M2RV99hQ!Z3N7c7CGYniy3jSpQcJFZ26u1L4RAeY5ztEwnXfrfsHMSREoSRQ3AOQtlHehsP__Tj1DS8U$ 
>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/jextract/pull/11__;!!ACWV5N9M2RV99hQ!Z3N7c7CGYniy3jSpQcJFZ26u1L4RAeY5ztEwnXfrfsHMSREoSRQ3AOQtlHehsP__Tj1DS8U$ 
>>>>> >
>>>>> [2] -
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jextract/blob/e184943f15e8df68c6122b8f7e49c0a910a3b773/build.gradle*L113__;Iw!!ACWV5N9M2RV99hQ!Z3N7c7CGYniy3jSpQcJFZ26u1L4RAeY5ztEwnXfrfsHMSREoSRQ3AOQtlHehsP__weEmPQE$ 
>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/jextract/blob/e184943f15e8df68c6122b8f7e49c0a910a3b773/build.gradle*L113__;Iw!!ACWV5N9M2RV99hQ!Z3N7c7CGYniy3jSpQcJFZ26u1L4RAeY5ztEwnXfrfsHMSREoSRQ3AOQtlHehsP__weEmPQE$ 
>>>>> >