Hi Erik, Unfortunately, just adding .cpp files to file list isn’t enough, as I mentioned in one of my previous emails[1], initially I did exactly that and linux-slowdebug build fails b/c c-linker was be used for .o files produced by cpp-compiler.
I guess something like [2] might work. I'll play w/ this idea and send final patch latch. — Igor [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-August/022922.html [2] TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT) > On Aug 23, 2018, at 11:31 PM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > Hello Igor, > > In TestFilesCompilation.gmk, there is no need to duplicate the whole macro > call. If you want to find .cpp as well as .c files, just add that to the one > list of files. The SetupNativeCompilation macro will automatically treat .c > and .cpp correctly. > > Regarding the .c/.cpp files for your vmtestbase tests that include all the > other files, this is an unfortunate solution, but I guess OK if it works. We > certainly didn't intend it that way. The macro SetupTestFilesCompilation was > intended for easily writing single file native exe and lib binaries without > having to modify any makefile. The expectation was that if anything more > complicated was needed (like multiple files per binary), we would just write > explicit SetupNativeCompilation calls for them in JtregNativeHotspot.gmk. It > now looks like we have a new pattern of source files/directories that turns > into native libraries, and we could of course create a new macro that > automatically generates compilation setups for them as well (given that file > or directory names makes it possible to automatically determine everything > needed). Of course, that change would be a separate cleanup possible if you > want to. > > /Erik > >> On 2018-08-20 15:59, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >> Hi all, >> >> could you please review the patch which moves all hotspot native test code >> to C++? this will guarantee that we always use C++ compilers for them (as an >> opposite to either C or C++ compiler depending on configuration), as a >> result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other >> clean ups and improve overall quality of the test code. >> >> the patch consists of two parts: >> - automatic: renaming .c files to .cpp, updating #include, changing >> JNI/JVMTI calls >> - semi-manual: adding extern "C" , fixing a number of compiler warnings >> (mostly types inconsistency), updating makefiles >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >> webrevs: >> - automatic: >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >> - semi-manual: >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>> 1899 lines changed: 879 ins; 61 del; 959 mod >> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >> testing: all hotspot tests + tier[1-3] >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >> >> Thanks, >> -- Igor >
