-
Enhancement
-
Resolution: Duplicate
-
P3
-
None
I had some kind of vague idea that lots of stuff in the calls to SetupNativeCompilation look the same, e.g.
LANG:=C,
CFLAGS:=$(CFLAGS_JDKLIB),
or if it's present, it follows a specific pattern, e.g.
MAPFILE:=$(JDK_TOPDIR)/makefiles/mapfiles/LIBNAME/mapfile-vers
etc.
Can this be used as a way to construct a simpler SetupNativeCompilation? Maybe an SetupJdkNativeCompilation, that has good default values for most fields, which only needs to be overridden if the defaults do not work.
This could tie in nicely withJDK-8001934 (build-infra: Unify all RC_FLAGS in CompileNativeLibraries.gmk), and it might also make DK-8001935 (build-infra: Is it possible to split or regroup CompileNativeLibraries.gmk?) less pressing, since it might make CompileNativeLibraries.gmk much smaller.
Other benefits will include:
* It is easier to add a new native library.
* We provide a good standard for new native libraries, and if they follow it, everything will be much easier.
* It paves the road for cleaning up non-conforming libraries.
LANG:=C,
CFLAGS:=$(CFLAGS_JDKLIB),
or if it's present, it follows a specific pattern, e.g.
MAPFILE:=$(JDK_TOPDIR)/makefiles/mapfiles/LIBNAME/mapfile-vers
etc.
Can this be used as a way to construct a simpler SetupNativeCompilation? Maybe an SetupJdkNativeCompilation, that has good default values for most fields, which only needs to be overridden if the defaults do not work.
This could tie in nicely with
Other benefits will include:
* It is easier to add a new native library.
* We provide a good standard for new native libraries, and if they follow it, everything will be much easier.
* It paves the road for cleaning up non-conforming libraries.
- duplicates
-
JDK-8199639 Introduce SetupJdkLibrary and SetupJdkExecutable
- Resolved