RFR: 8326583: Remove over-generalized DefineNativeToolchain solution

[Julian Waters]

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

!!!

Not to be a party pooper, but this seems like it removes pretty some useful functionality from the build system. What if this is needed down the line? On the motivation of this change, TOOLCHAIN_LINK_CXX is pretty clear that the linker to be used is g++ instead of gcc for instance, while the new LANG parameter makes it look like SetupNativeCompilation only accepts and compiles C++ files if C++ is passed, and only C files if the new default of C is passed (For anyone looking in on this Pull Request who isn't familiar with the build system, it can compile a mix of both without issue). I'm not particularly sure this is a good idea, since a lot of flexibility seems to be lost with this change. I don't seem to see any simplification to SetupNativeCompilation either, maybe I'm missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1962269640