RFR: JDK-8077824: Introduce DefineNativeToolchain to handle toolchain configurations

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Thu Apr 16 08:42:10 UTC 2015

On 2015-04-15 11:24, Erik Joelsson wrote:
> The macro SetupNativeCompilation handles various overrides of the 
> compiler and linker used for compilation. There is also a LANG option, 
> which implies that it needs to be told if it's compiling C or C++ when 
> in reality, this is handled automatically. The real purpose of the 
> LANG option is just to decide which executable to use for linking in 
> certain conditions/platforms.
> I would like to put some more structure around this by introducing a 
> new macro, DefineNativeToolchain. There s a default and a couple of 
> others, extending the default, for linking with the C++ compiler, 
> building for the build platform etc. These definitions will help 
> ensure that all the necessary executables and options are overridden 
> for each of these usecases.

In general, I'm very happy with this. It's a nice encapsulation!

However, I do have a bunch of issues/questions:

* AR is missing from the documentation of DefineNativeToolchain.

* LDCXX is mentioned in the documentation of DefineNativeToolchain, but 
not used. It seems that it should not be used there, but it should be 
removed from the documentation.

* DefineNativeToolchain seems to do nothing if EXTENDS is not set. This 
is since all the "magic" is done by NamedParamsMacroTemplate. Maybe this 
should be explained in a comment.

* The comment "LANG C or C++" should be removed for SetupNativeCompilation.

* The call to $(CC) when processing RC files, should (perhaps?) be $1_CC 

* $1_MT should be in VARDEPS. (Maybe not really a regression, but it 
would be nice to fix it now)

* I can't find that $1_CC is in VARDEPS either, should probably go in 
somewhere. In general, all the TOOLCHAIN variables should go in VARDEPS.

* BUILD_LIBJAWT seems to have lost a LANG := C++ but not gained a 
BUILD_LIBSUNMSCAPI, BUILD_LIBJSOUNDDS and the accessbridge stuff in 

Is there some reason that the change here does not change the resulting 
link behavior? Or is this an oversight?


More information about the build-dev mailing list