On 2014-05-02 08:53, Staffan Larsen wrote:
On 1 maj 2014, at 07:45, David Holmes wrote:
On 30/04/2014 9:39 PM, Staffan Larsen wrote:
The question is whether it is worth it relative to the size of the
problem.
I think we will see a large influx of these kinds of tests, especially in the
ho
On 1 maj 2014, at 07:45, David Holmes wrote:
> On 30/04/2014 9:39 PM, Staffan Larsen wrote:
>>
>> On 30 apr 2014, at 11:39, David Holmes wrote:
>>
>>> Hi Staffan,
>>>
>>> On 25/04/2014 10:02 PM, Staffan Larsen wrote:
There are a couple of jtreg tests today that depend on native componen
Dmitry,
Beyond Staffan's proposal for jtreg to provide tests with a pointer to
the location of precompiled native code, there are no plans to change
the way jtreg execute tests, processes action tags like @build, @run,
etc.
-- Jon
On 05/01/2014 09:12 AM, Dmitry Samersoff wrote:
Staffan,
Coup
Staffan,
Couple of tests require both Java and native code, so compiling it's all
into the single directory might be a problem. Some test used to access
additional data in TESTSRC so we have to copy it as well.
One of possible solution is to allow the tests to support two
independent steps - "bui
On 30/04/2014 9:39 PM, Staffan Larsen wrote:
On 30 apr 2014, at 11:39, David Holmes wrote:
Hi Staffan,
On 25/04/2014 10:02 PM, Staffan Larsen wrote:
There are a couple of jtreg tests today that depend on native components
(either JNI libraries or executables). These are handled in one of t
On 30 apr 2014, at 11:39, David Holmes wrote:
> Hi Staffan,
>
> On 25/04/2014 10:02 PM, Staffan Larsen wrote:
>> There are a couple of jtreg tests today that depend on native components
>> (either JNI libraries or executables). These are handled in one of two ways:
>>
>> 1) The binaries are p
Hi Staffan,
On 25/04/2014 10:02 PM, Staffan Larsen wrote:
There are a couple of jtreg tests today that depend on native components
(either JNI libraries or executables). These are handled in one of two ways:
1) The binaries are pre-compiled and checked into the repository (often inside
jar fi
On 04/28/2014 11:18 AM, Sergey Bylokhov wrote:
Hello,
I know it is crazy idea but why we cannot prebuild all tests at once
and use only one jar like jck do?
Because the test execution model is intentionally different from JCK and
other test harnesses like TestNG and JUnit.
jtreg specifies
Hello,
I know it is crazy idea but why we cannot prebuild all tests at once and
use only one jar like jck do?
--
Best regards, Sergey.
Yes, can you file an Enhancement for CODE-TOOLS/tools/jtreg
-- Jon
\On 04/28/2014 11:03 AM, Staffan Larsen wrote:
The change in jtreg that I would like to see is the addition of a flag to specify the
path of the test binaries. I’m thinking something like “-natives:”. This
would do two things:
On 28 apr 2014, at 20:05, Jonathan Gibbons wrote:
> On 04/28/2014 10:57 AM, Staffan Larsen wrote:
>> Good point. I’ve been calling the target that build the test “build-tests”
>> which I’m not particularly fond of. “test-bundle” on the other hand seems to
>> imply an actual bundling (zipping,
On 04/28/2014 10:57 AM, Staffan Larsen wrote:
Good point. I’ve been calling the target that build the test “build-tests” which I’m
not particularly fond of. “test-bundle” on the other hand seems to imply an actual
bundling (zipping, tarring) of the files (and maybe that was what you were referr
The change in jtreg that I would like to see is the addition of a flag to
specify the path of the test binaries. I’m thinking something like
“-natives:”. This would do two things:
- Set the java.library.path when invoking tests. This is needed for
System.loadLibrary() to work.
- Set a test.nati
On 28 apr 2014, at 19:31, Jonathan Gibbons wrote:
> On 04/28/2014 01:08 AM, Staffan Larsen wrote:
>> If you prefer to not use the makefile to run tests, you would have to do two
>> step: first compile native tests (using the makefiles) and then run jtreg
>> manually. You would then have to tel
On 04/28/2014 01:08 AM, Staffan Larsen wrote:
If you prefer to not use the makefile to run tests, you would have to do two
step: first compile native tests (using the makefiles) and then run jtreg
manually. You would then have to tell jtreg where the compiled tests are.
There should be a sepa
Hi Christian,
Yes, that is my intention. If there is a makefile in the folder, that file will
be invoked (in the context of the “normal” makefiles). I wrote a little about
this in my response to Jon. The idea is that for simple native components the
compilation is automagic, but it is also poss
Hi Staffan,
This sounds like a great proposal that would solve many of our issues with
tests requiring native code. Would it be possible for the make system to
pick up a custom makefile from a test folder? The use cases I see are:
1. Launcher type tests (we have a few of these), these needs to b
On 25 apr 2014, at 18:09, Martin Buchholz wrote:
> I don't see a good solution. Conceptually, the tests are built/executed
> independently of the jdk they are testing. But it would be crazy to have a
> separate configure/make infrastructure for each native test. If you build
> the test native
On 25 apr 2014, at 17:31, Jonathan Gibbons wrote:
> I'll quibble over the phrase "the same makefile logic".
>
> I think it is OK to use the same Makefile infrastructure (e.g. the
> configure.sh mechanism) and the same top level Makefile, but at some level
> this is going to need to be distinc
I'll quibble over the phrase "the same makefile logic".
I think it is OK to use the same Makefile infrastructure (e.g. the
configure.sh mechanism) and the same top level Makefile, but at some
level this is going to need to be distinct Makefile logic specific to
compiling the code for the tests
20 matches
Mail list logo
