Proposal: jtreg tests with native components

[Staffan Larsen]

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 possible to have a complete makefile when the simple thing is not enough. 

/Staffan 



On 28 apr 2014, at 14:20, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:

> 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 be compiled
> into an executable 
> 2. Test libraries that might depend on being compiled with certain
> compiler/linker flags (don't think we have tests like this today though).
> 
> Thanks for working on this :)
> 
> Thanks,
> Christian
> 
> -----Original Message-----
> From: jtreg-dev [mailto:jtreg-dev-bounces at openjdk.java.net] On Behalf Of
> Staffan Larsen
> Sent: Friday, April 25, 2014 8:03 AM
> To: build-dev at openjdk.java.net build-dev; jtreg-dev at openjdk.java.net
> Subject: Proposal: jtreg tests with native components
> 
> 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 files).
> 2) The test will try to invoke a compiler (gcc, cl, .) when the test is
> being run.
> 
> Neither of these are very good solutions. #1 makes it hard to run the setup
> the test for all platforms and requires binaries in the source control
> system. #2 is hit-and-miss: the correct compiler may or may not be installed
> on the test machine, and the approach requires platform specific logic to be
> maintained.
> 
> I would like to propose that these native components are instead compiled
> when the product is built by the same makefile logic as the product. At
> product build time we know we have access to the (correct) compilers and we
> have excellent support in the makefiles for building on all platforms.
> 
> If we build the native test components together with the product, we also
> have to take care of distributing the result together with the product when
> we do testing across a larger number of machines. We will also need a way to
> tell the jtreg tests where these pre-built binaries are located.
> 
> I suggest that at the end of a distributed build run, the pre-built test
> binaries are packaged in a zip or tar file (just like the product bits) and
> stored next to the product bundles. When we run distributed tests, we need
> to pick up the product bundle and the test bundle before the testing is
> started.
> 
> To tell the tests where the native code is, I would like to add a flag to
> jtreg to point out the path to the binaries. This should cause jtreg to set
> java.library.path before invoking a test and also set a test.* property
> which can be used by test to find it's native components.
> 
> This kind of setup would make it easier to add and maintain tests that have
> a native component. I think this will be especially important as more tests
> are written using jtreg in the hotspot repository.
> 
> Thoughts on this? Is the general approach ok? There are lots of details to
> be figured out, but at this stage I would like to hear feedback on the idea
> as such.
> 
> Thanks,
> /Staffan
> 
>