On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie <i...@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. First some general remarks. The thing about generalization is that you need to take it in right enough doses -- too much is just as problematic as too little. You can represent any program with a Turing machine that can read or write, and move a head back and forth. That is extremely general, and completely hopeless to program in. The right amount of generalization is reached when it helps you express the underlying ideas in a easy-to-understand way. If you got duplication, then it means something needs to be more generalized. But if you have a general solution that is only ever used in a single way, then you have over-generalization. Secondly, trust the VCS. Keeping code around since it might be "needed down the line" is a very bad reason. If we will need it again, we can restore it from the history. My experience is that these things practically never happens -- even if you need something similar in the future, the requirements are almost always different enough that the old system did not work anyway. And now over to more specific comments about this patch. There was a historic need for this function. When it was created, we started a new build system from the ground up to consolidate a myriad of different ways to build parts of the product. There were no good standardized toolchain, and we had a requirement to really handle different toolchains. Then during the years we have chipped away at all the odds bits and pieces, until the entire build uses (basically) the same toolchain -- the only difference is the linker argument. And, of course, the orthogonal question if we're targeting the build machine or the target machine, when cross-compiling. This is a very clear concept in the rest of the build system, but it was diffused in the toolchain profiles by making it look like we just have another "profile", like it was another version of gcc. So in this PR we replace a very general idea of a "profile" with two distinct options that we really care about -- what platform to target, and how we call the linker. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1963821493
