On Sat, 24 Feb 2024 06:04:40 GMT, Julian Waters <jwat...@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? I renamed LANG to LINK_TYPE, to not make it overly general. @TheShermanTanker Are you okay with this patch now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965176131
