cc: quality-discuss
bcc: code-tools-dev
This is now turning into a discussion on the way we want to modify tests
to accommodate WSL, and so I think we should carry on this discussion on
the quality-discuss@openjdk.java.net alias. I want to make sure that we
get input from the folk that write, debug and maintain these tests. Once
we decide on how we would like to modify the coding patter in tests,
then we can determine how best to support that from jtreg.
Of particular interest, it would help to know how these tests are used
these days. It used to be the case that it was important for these shell
tests to be able to run standalone, without the use of jtreg at all. If
that is still the case, we cannot overly rely on jtreg to set lots of
variables. If we only ever run shell tests from jtreg these days, they
we could remove a bunch of boilerplate and have jtreg set more info in
env variables. The reality is probably somewhere in between, which is
why we need test authors to chime in here.
-- Jon
On 01/18/2019 07:59 PM, Andrew Luo wrote:
EXE_SUFFIX being .exe guarantees you that it is a Windows JVM under test (WSL
currently), but I think EXE_SUFFIX could also be used for Cygwin as well (even
though it is not used currently). Or perhaps another emulation layer, if we add
support for yet another one in the future. But aside from that, I think from the
perspective of clarity, it's not obviously (to someone that has no context) that
EXE_SUFFIX == .exe => WSL and not Cygwin, because EXE_SUFFIX could be .exe on
all Windows platforms. But if we set WSL_TARGET == windows, it's pretty obvious
that that environment variable means WSL. Of course, the possibility of
supporting another emulation layer is purely theoretical at this point, so if you
have a strong preference, it doesn't matter that much to me.
But if I had a choice between the above (EXE_SUFFIX == .exe => WSL_TARGET =
windows) and WSL_TARGET == windows => EXE_SUFFIX = .exe, I would prefer the
latter, because EXE_SUFFIX doesn't explicitly guarantee you are on WSL.
Anyways, I want to hear any other thoughts on this...
Thanks,
-Andrew
-----Original Message-----
From: Jonathan Gibbons <jonathan.gibb...@oracle.com>
Sent: Friday, January 18, 2019 4:36 PM
To: Andrew Luo <andrewluotechnolog...@outlook.com>;
code-tools-...@openjdk.java.net
Subject: Re: [PATCH] Fix for EXE_SUFFIX being set for WSL having no effect
On 01/18/2019 03:56 PM, Jonathan Gibbons wrote:
On a (somewhat related note), another thing I noticed is that some
scripts have logic such as:
OS=`uname -s`;
# Set classpath separator
case "$OS" in
Windows* | CYGWIN* )
SEP=";"
;;
* )
SEP=":"
esac
However, the classpath separator would depend on the platform of the
JVM under test (; for a Windows JVM under test, : for a Linux JVM
under test). I could copy the above logic to detect the JVM under
test in the script, but this seems like overkill just to check whether
your target JVM is Windows or Linux. So perhaps we could add another
environment variable, say WSL_TARGET, which would either be set to
"windows" for a Windows WSL target, or empty for Linux WSL
target/non-WSL. That way the above logic could be rewritten:
OS=`uname -s`;
# Set classpath separator
case "$OS" in
Windows* | CYGWIN* )
SEP=";"
;;
* )
if [ "x${WSL_TARGET}" = "xwindows" ]; then
SEP=";"
else
SEP=":"
fi
esac
Just reading this fragment of your message, I think I'm beginning to see what you may be trying to
do. But WSL_TARGET seems like the wrong way to go. If you need to use WSL_TARGET to fix up the
"*" case, that means you executed "case" on the wrong value in the first place.
How about the following direction:
OS=`if [ "x${EXE_SUFFIX}" = "x.exe" ]; then echo "Windows_WSL" ; else uname -s; fi`; #
Set classpath separator case "$OS" in
Windows* | CYGWIN* )
SEP=";"
;;
* )
SEP=":"
esac
or finesse it a bit:
SYSTEM=`if [ "x${EXE_SUFFIX}" = "x.exe" ]; then echo "WSL" ; else uname -s; fi`; # Set
classpath separator case "$SYSTEM" in
Windows* | CYGWIN* | WSL )
SEP=";"
;;
* )
SEP=":"
esac
In other words, isn't EXE_SUFFIX already indirectly telling you that its a
Windows JVM under test?
-- Jon
