building jtreg, and running tests

Fri Nov 1 08:30:31 PDT 2013

On 10/31/2013 08:16 PM, Mike Duigou wrote:
>
> On Oct 31 2013, at 19:40 , Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>> 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. 
>
> I believe we will have to move towards this.

Look for this later today. I ran out of time and energy yesterday, but I 
know the edits to I want to make.

>
>> Those folk that invoke jtreg.jar file directly will need to do the 
>> translation themselves.
>
> I agree. The java -jar command should only be seeing native paths.
>
>> 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.
>
> I have been working on the test/Makefiles and have been thinking where 
> to properly make the split between native paths and cygwin paths. 
> Currently it's done all in the makefile but perhaps in the jtreg 
> script wrapper might be a better place (or more convenient) since it 
> is going to get invoked anyway and will always be invoked from within 
> a posix-like environment like either cygwin or mingw. This would also 
> eliminate the need to have platform specific code in the test 
> makefiles which would be nice.

I was using the old JDK makefiles as a guideline/reference, where the 
methodology within the makefiles was to use mixed paths (drive letters 
plus "/"). There are comments from Kelly within the makefiles as to the 
rationale. It would be interesting to talk to the current build team 
about the methodology within the new build, and to follow their lead 
within the test makefiles.

>
> Another option I have considered: Windows command scripts to replace 
> or supplement the jtreg and jtdiff scripts that would be fully windows 
> native. I'd like to consider eliminating the duplicate bin directories 
> and going with a single bin directory like Ant does.

I'm not sure what you mean here. By  "fully windows native" do you mean 
a .BAT file? How does that go along with the use of a single bin directory?

FWIW, I'd support going with a single bin directory; the duplicate 
directoris are a historical anachronism; the only reason I've held off 
is to avoid breaking infrastructure which assumes the existence of the 
extra path level.  Maybe if enough systems use test/Makefile, we can 
paper over the transition in test/Makefile.

-- Jon

>
> Mike
>
>
>>
>> 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/20131101/0b3827a0/attachment-0001.html 