On 1 maj 2014, at 07:45, David Holmes <david.hol...@oracle.com> wrote:
> On 30/04/2014 9:39 PM, Staffan Larsen wrote: >> >> 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. > > 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 hotspot repo. > >>> >>> 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? > > You _may_ be able to, you may not. I know we already had issues where the > CFLAGS as being used for the JDK sources also got applied to building the > code-generator utility programs and that didn't work correctly. Here's sample > CFLAGS from a JDK build > > CFLAGS_JDKLIB:= -W -Wall -Wno-unused -Wno-parentheses -pipe > -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer > -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"i586"' -Di586 > -DRELEASE='"$(RELEASE)"' > -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include > -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include/linux > -I/export/users/dh198349/jdk8u-dev/jdk/src/share/javavm/export > -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/javavm/export > -I/export/users/dh198349/jdk8u-dev/jdk/src/share/native/common > -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/native/common -m32 > -fno-strict-aliasing -fPIC > > Does that make sense for compiling a test? Does it depend on whether we are > building a native library or a native executable? I think they make sense, at least initially. If not, we can tune them, but that "tuning” will be in one central location and not spread out in a lot of shell scripts. I also plan to allow individual tests to override the flags if necessary (for example to link with X11). For executables there is CFLAGS_JDKEXE. Thanks, /Staffan > >>> >>> 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. > > :) It wasn't SQE, it was your project as referenced in a few bug reports last > August/September. > > David > > >> /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 >>>> >>
