building jtreg, and running tests

[Jonathan Gibbons]

Francis,

The problem is not the type of file separator (\ vs. /) but the use of 
/cygdrive paths.

Java, like most other programs that run natively on Windows, does not 
recognize cygwin file paths, which are only valid within the general 
cygwin environment. This extends to jtreg (or more specifically, the 
classes in jtreg.jar).  Separately, even though \ is the standard file 
separator on Windows, it has long been specified that / is also a valid 
separator on Windows.   Put these two statements together, and it 
follows that when you pass a path like /cygdrive/Z/my/directory/file.txt 
to a Java program, the program will typically interpret that as 
X:\cygdrive\Z\my\directory\file.txt, where X is the drive letter for the 
current working directory.  Typically, that path will not exist and you 
will get some sort of "file not found error" if you try and access that 
file.  And that is what you are seeing below.

There are two solutions, each with their own advantages and disadvantages:

 1. Use "mixed style" paths, like Z:/my/directory/file.txt. Windows (and
    java programs) will accept them as valid paths, but the ":"
    character can cause problems in the cygwin world
 2. Use the standard cygpath utility to convert between the different
    formats as needed.

See http://cygwin.com/cygwin-ug-net/using-effectively.html for more 
information. In particular, see this section:
>
>
>       Pathnames
>
> Windows programs do not understand POSIX pathnames, so any arguments 
> that reference the filesystem must be in Windows (or DOS) format or 
> translated. Cygwin provides the *cygpath* utility for converting 
> between Windows and POSIX paths. A complete description of its options 
> and examples of its usage are in the section called "cygpath" 
> <http://cygwin.com/cygwin-ug-net/using-utils.html#cygpath>, including 
> a shell script for starting Windows Explorer in any directory. The 
> same format works for most Windows programs, for example
>
> |notepad.exe "$(cygpath -aw "Desktop/Phone Numbers.txt")"|
>
> A few programs require a Windows-style, semicolon-delimited path list, 
> which *cygpath* can translate from a POSIX path with the |-p| option. 
> For example, a Java compilation from *bash* might look like this:
>
> |javac -cp "$(cygpath -pw "$CLASSPATH")" hello.java|
>
> Since using quoting and subshells is somewhat awkward, it is often 
> preferable to use *cygpath* in shell scripts.
>

So, where does that leave jtreg?

Well, internally the code is just a Java program, and so does not (will 
not) understand /cygdrive paths.  But, it is reasonable to expect that 
those parts of the jtreg ecosystem that live in the cygwin world should 
be aware of /cygdrive paths.

Earlier today, I pushed fixes that should allow /cygdrive paths to be 
used when building jtreg.
     http://hg.openjdk.java.net/code-tools/jtreg/rev/8f44b4e1f37b
and tolerate the use of /cygdrive in JT_HOME
     http://hg.openjdk.java.net/code-tools/jtreg/rev/caf396306070

Your example has opened up another case that would be good to address, 
command line args to jtreg.  For those folk that invoke jtreg through 
the standard script, we could reasonably translate /cygdrive/X into X: 
for all drive letters. Those folk that invoke jtreg.jar file directly 
will need to do the translation themselves.

Note:

Some folk may use jtreg by means of the various test targets in the 
various Makefiles. I don't know what the conventions are for accepting 
/cygdrive paths in the makefiles, or whether the mixed format is 
expected/required. Maybe someone more familiar with using those 
makefiles on Windows with Cygwin can comment.

For another day:

What about MSYS/MinGW?
If you want your head to explode, try reading 
http://www.mingw.org/wiki/Posix_path_conversion

-- Jon


On 10/31/2013 01:27 PM, Francis ANDRE wrote:
> Hi Jon
>
> I run all the jdk8 test on WXP/Cygwin with your latest version of 
> jtreg and found this problem:
>
> $ 
> JT_JAVA=/cygdrive/Z/JDK/jdk8/build/windows-x86-normal-server-release/images/j2sdk-image 
> Z:/JDK/jt
> reg/build/images/jtreg/win32/bin/jtreg -J-Xmx512m -vmoption:-Xmx768m   
> -a -ignore:quiet -v:fail,e
> rror,nopass 
> -r:Z:/JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/JTreport
>  -w:Z:/JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/JTwork 
> -jdk:/cygdrive/Z/JDK/j
> dk8/build/windows-x86-normal-server-release/images/j2sdk-image 
> -agentvm -concurrency:2
>             . || ( status=$?; if [ $status -ge 3 ]; then exit $status 
> ; fi ;     echo $status > Z:/
> JDK/jdk8/LANGTO~1/build/WINDOW~1/test/LANGTO~1/jtreg/status.txt )
> Error: JDK not found: 
> \cygdrive\Z\JDK\jdk8\build\windows-x86-normal-server-release\images\j2sdk-imag
> e
>
> The error JDK not found is coming from the replacement of the / by \ 
> in the JT_JAVA environment variable. In effect, the cygwin path should 
> be with "/" and not "\"... -- I know, it is a nightmare 
> --...hopefully,we will beat it!
>
> Francis
>
> Le 31/10/2013 02:41, Jonathan Gibbons a écrit :
>> Spurred on by the recent discussions and contributions, I've pushed 
>> some more changes to the jtreg repo to make it easier to build, and 
>> even run most of the tests, on Windows.
>>
>> (I still recommend using Linux instead, when that is an option.)
>>
>> The cygwin world is definitely problematic, especially for running 
>> the jtreg tests, since cygwin presents a different view of the file 
>> system to the native Windows view seen by Java programs. The problems 
>> mostly show up in tests that check that output from jtreg, especially 
>> when using diff, grep, etc.  For the time being, I've disabled the 
>> tests in 11 of the 70 test files in make/tests/*.gmk, meaning that 
>> the tests in the remaining 59 files all run successfully.
>>
>> For what its worth, my setup is to have a cygwin symlink from /opt to 
>> C:/opt (i.e. /cygdrive/c/opt) which means that I can place all my 
>> dependencies in /opt//package///version/ and can then see them from 
>> both the cygwin world and the Windows world, without having to use 
>> path-munging utilities like cygpath all over the place.
>>
>> I'm open to more direct support of /cygdrive paths in the build, and 
>> wonder if folk have any good tips and tricks for minimising the 
>> obtrusiveness of the conversion functions in the composite world of 
>> GNU make and cygwin, such that the resulting code runs on Cygwin and 
>> POSIX systems.
>>
>> -- Jon
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20131031/f9265c23/attachment-0001.html