RFR: 8326583: Remove over-generalized DefineNativeToolchain solution

[Magnus Ihse Bursie]

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.

I could have chosen to name the `LANG` argument e.g. `LINKER_LANG`. If you insist, I can go back and rename it like this also. But there was a reason I chose the more general `LANG`, and that is because we have other unresolved issues regarding C vs C++ in the build. We don't handle CFLAGS vs CXXFLAGS very well, and we have several convoluted fixes (that just smells "black magic") to get the build to work. My instinct is that these are highly correlated to the choice of linker -- basically, in the old build system, there were a difference between C-libs anc C++-libs that were not properly carried over to the new build system. My intention is to continue this work by aligning flags etc with this property as well. But this is future work, so one could argue that with just this patch, the name `LANG` is overly broad. 

I thought it was okay, in the light of future development, and the wish to keep argument names succinct, but if you object I can rename it.

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

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