On 2014-05-02 08:53, Staffan Larsen wrote:
On 1 maj 2014, at 07:45, David Holmes <david.hol...@oracle.com> 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
hotspot repo.
I don't doubt it will be worth 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?
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.
For the initial proof of concept, just using the existing CFLAGS_JDKLIB
and CFLAGS_JDKEXE will be fine. Going forward, I would like to see
CFLAGS_TESTLIB and CFLAGS_TESTEXE being provided by configure. There
will certainly be a lot of common things for both product and test libs
and as pointed out above, some differences too. We should leverage the
logic already present in our configure script to provide suitable defaults.
/Erik
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
