-
Enhancement
-
Resolution: Fixed
-
P3
-
8
There are a lot of more or less copied code regarding RC_FLAGS in CompileNativeLibraries.gmk. When I had to change /D to -D for msys support, it ended up being hundreds of changes.
We can do better.
A first and minimum step could be to have a make macro like
$(call MakeRCFlags,"verify.dll","verify",0x2L)
that expands to
$(RC_FLAGS) \
-D "JDK_FNAME=verify.dll" \
-D "JDK_INTERNAL_NAME=verify" \
-D "JDK_FTYPE=0x2L"
But I'd really like to see this tighter integrated into SetupNativeCompilation.
For instance, is ever JDK_INTERNAL_NAME different from LIBRARY, and JDK_FNAME different from LIBRARY.dll? We should only have to type that if it does not follow the standard and needs to be overridden.
We can do better.
A first and minimum step could be to have a make macro like
$(call MakeRCFlags,"verify.dll","verify",0x2L)
that expands to
$(RC_FLAGS) \
-D "JDK_FNAME=verify.dll" \
-D "JDK_INTERNAL_NAME=verify" \
-D "JDK_FTYPE=0x2L"
But I'd really like to see this tighter integrated into SetupNativeCompilation.
For instance, is ever JDK_INTERNAL_NAME different from LIBRARY, and JDK_FNAME different from LIBRARY.dll? We should only have to type that if it does not follow the standard and needs to be overridden.
- relates to
-
JDK-8199639 Introduce SetupJdkLibrary and SetupJdkExecutable
-
- Resolved
-