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
TOOLCHAIN := TOOLCHAIN_LINK_CXX. The same goes for LIBAWT_LANG,
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