- 
    Enhancement 
- 
    Resolution: Fixed
- 
     P3 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
 
-