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.tornqv...@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-boun...@openjdk.java.net] On Behalf Of > Staffan Larsen > Sent: Friday, April 25, 2014 8:03 AM > To: build-dev@openjdk.java.net build-dev; jtreg-...@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 > >
