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

[Magnus Ihse Bursie]

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 
now.

* $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 
TOOLCHAIN := TOOLCHAIN_LINK_CXX. The same goes for LIBAWT_LANG, 
BUILD_LIBSUNMSCAPI, BUILD_LIBJSOUNDDS and the accessbridge stuff in 
Lib-jdk.accessibility.gmk.

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

/Magnus