On 30 apr 2014, at 11:39, David Holmes <david.hol...@oracle.com> 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 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. > > #2 is far from perfect but ... > >> 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. > > don't under estimate the complexity involved in building then "distributing" > the test binaries. I don’t. It will be complicated, but I’m sure we can do it. > > You will still need to maintain platform specific logic as you won't > necessarily be able to use the CFLAGS etc that the main build process uses. Can you explain more? Why can’t I use CFLAGS as it is? > > Also talk to SQE as I'm pretty sure there is an existing project to look at > how to better handle this, at least for the internal test suites. I have talked to SQE. I don’t know of any other projects to handle this. /Staffan > > David > ----- > >> 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 >>
