> Hi all, > > please review this smaller patch to the build system. This patch changes what > the build system will do when there are multiple configurations available and > none has been selected (neither via `CONF` nor via `SPEC`). Instead of > printing an error message (current behavior) the build system will instead > check if the name of any configuration exactly matches the name of the > checked out Git branch. If so, then that configuration will be built. > > The rationale for this change is that many developers (including me) use > branches to work on multiple things concurrently. Having (at least) one > configuration per branch, named after the branch, is a very natural model > then for setting up one's build configurations. Having the build > configuration corresponding to the checked out Git branch built automatically > is then very convenient (instead of typing `make CONF=$(git branch > --show-current)` every time). > > A couple of design considerations: > - why use `$$(shell command -v git 2>/dev/null)` instead of `$$(GIT)` from > autoconf? Because we don't have a `spec.gmk` available because we haven't > chosen a configuration yet, so we don't have `$$(GIT)`. > - why use `git rev-parse --abbrev-ref HEAD` instead of `git branch > --show-current`? Because `git rev-parse --abbrev-ref` has been around since > [2009](https://github.com/git/git/commit/a45d34691ea624e93863e95706eeb1b1909304f3) > and `git branch --show-current` was introduced in Git 2.22 in 2019 (plus > that `rev-parse --abbrev-ref` works with a detached `HEAD`). `git rev-parse > --is-inside-work-tree` is from > [2007](https://github.com/git/git/commit/892c41b98ae2e6baf3aa13901cb10db9ac67d2f3), > but I think requiring a Git installation more recent than 2009 should be ok. > - why match the branch name exactly instead of a looser matching? This could > be beneficial if branches are named e.g. `$(git branch > --show-current)-fastdebug`, but I wanted to start out with something strict > and then the matching can be made looser if needed. > - is this backwards compatible? Yes, at least I think so. Previously the > build system would return an error but now it might build a configuration, > that seems compatible. The patch does not interfere at all with the code > paths where `CONF` or `SPEC` has been set. > > ### Testing > - [x] Tested locally on macOS/aarch64 and Linux/x64 with and without > configurations matching the named Git branch. > - [x] Tested locally on macOS/aarch64 and Linux/x64 without a Git client. > - [x] Tested locally on macOS/aarch64 a...
Erik Helin has updated the pull request incrementally with one additional commit since the last revision: Fuzzier matching ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14202/files - new: https://git.openjdk.org/jdk/pull/14202/files/b233d60f..db7c8b6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14202&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14202&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14202/head:pull/14202 PR: https://git.openjdk.org/jdk/pull/14202
