As long as we understand/document the impact on tests, it's OK if any
related changes are done separately, in a timely manner. But if the
existing "Linux" case works, that's good to know.
-- Jon
On 01/07/2019 03:27 PM, Andrew Luo wrote:
Hi Jon,
I had thought about this a little more earlier and I was intending to
handle these changes separately. “uname -s” returns Linux on WSL.
You can distinguish using “uname -r" containing “Microsoft” (this is
what we do elsewhere). However, the script itself cannot determine
this independently because you can target either Linux or Windows from
WSL (if you target Linux from WSL, then everything already works,
using the Linux code path). Most likely, gmake will need to pass in
to the script (most likely via another environment variable, such as
-e:WSL_WINDOWS_TARGET=1) and then the script will have to have an
additional check in the “uname -s" == Linux case).
Thanks,
-Andrew
*From:*Jonathan Gibbons <[email protected]>
*Sent:* Monday, January 7, 2019 2:34 PM
*To:* Andrew Luo <[email protected]>;
[email protected]
*Subject:* Re: [PATCH] Fixes for running tests on WSL
Andrew,
Setting aside whatever changes might be needed for jtreg itself, what
will need to be done to any shell tests?
For example, the following pattern is common in many of the shell
tests, with the general expectation that on Windows, CYGWIN will be
selected.
# set platform-dependent variables
OS=`uname -s`
case "$OS" in
AIX | Darwin | Linux | SunOS )
NULL=/dev/null
PS=":"
FS="/"
;;
CYGWIN* )
NULL=/dev/null
PS=";"
FS="/"
;;
Windows* )
NULL=NUL
PS=";"
FS="\\"
;;
* )
echo "Unrecognized system!"
exit 1;
;;
esac
KEYTOOL=${TESTJAVA}${FS}bin${FS}keytool
If nothing else, what does `uname -s` return when using WSL?
I think we should understand the impact on the tests before pushing
any changes in this area.
-- Jon
On 01/06/2019 11:34 AM, Andrew Luo wrote:
Hi Everyone,
I've gotten shell tests to run on WSL with some changes to jtreg and a small change to
the OpenJDK gmake files. Most of them are still not passing (I believe one or two of them
did just work out of the box after these changes as failures + error count dropped; previous
errors + previous failures < current failures; also "errors" dropped to zero),
as the scripts themselves will need to be changed, however, at least now they can actually
run... My patch with proposed changes are attached.
I've sent the corresponding jtreg changes to the code-tools-dev mailing
list:https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-January/000464.html
Let me know if you have any feedback/comments.
Thanks,
-Andrew