On Wed, 2 Mar 2022 08:11:51 GMT, TheShermanTanker <d...@openjdk.java.net> wrote:
> Currently the only other option for manually configuring the build platform > while cross compiling are devkits, which don't work on certain systems and > are also more focused on differentiating the build and target compilers > instead. This patch adds the ability to explicitly set the build platform > through a new option, which can be especially helpful for when autodetection > fails and devkits cannot be relied on, and also for simpler cross compilation > cases (Like the one described in building.md) > > This also removes support for the legacy cross compilation flags as well. > > WIP: Translation from markdown to html As Thomas says, it would have been much better if you raised the issue on the build-dev mailing list first. This does not seem to be the right way to resolve your problem. I have several objections to this PR. There is no need to remove support for the traditional autoconf arguments. Sure, it's confusing and does not match our build model, but we don't know who are actually using it out in the wild nevertheless. We have the functionality. Don't remove it. If we are to add a new argument to configure to specify the build platform, it should align with existing terminology. Just as --openjdk-target matches the OPENJDK_TARGET_* variables, so should a new argument match the OPENJDK_BUILD_* variables. That is, it should be named --openjdk-build. That said, I'm not even sure we *need* a new argument. If I understand you correctly, all you want to do is to be able to set --openjdk-target *and* use the traditional autoconf --build at the same time, right? We're currently blocking this since it was assumed users were doing something wrong, but there might be good reasons for doing this. And finally, changes in building.md should reflect the current line length of 80. And any changes needs to be updated into building.html (by running `make update-build-docs` with a proper version of pandoc). But once again, I don't think the current approach is a good one. ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7656
