[pull] master from git:master#45
Merged
pull[bot] merged 29 commits intoturkdevops:masterfrom May 6, 2025
Merged
Conversation
* es/meson-build-skip-coccinelle: meson: disable coccinelle configuration when building from a tarball
Newer compiler versions, like GCC 10 and Clang 12, have built-in functions for bswap32 and bswap64. This comes in handy, for example, when targeting CLANGARM64 on Windows, which would not be supported without this logic. Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
CLANGARM64 is a relatively new MSYSTEM added by the MSYS2 team. In order to have Git build correctly for this platform, let's add some configuration for it to config.mak.uname. Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It does not compile there, and seeing as nedmalloc has been pretty much unmaintained since at least November 2017, as per ned14/nedmalloc#20 (comment), there is also no hope that any fixes will materialize there. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> [jc: adjust config.mak.uname for c18400c] Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git for Windows/ARM64 settled on using `clang` to compile `git.exe`, and hence needs to run in a system where `MSYSTEM` is set to `CLANGARM64` and the prefix to use is `/clangarm64`. We already did that in the `MINGW` arm, i.e. for regular Git for Windows builds using MINGW GCC (or `clang`'s shim pretending to be GCC), now it is time to do the same in the MS Visual C part. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> [jc: adjust config.mak.uname for c18400c] Signed-off-by: Junio C Hamano <gitster@pobox.com>
In fb5e337 (mingw: move Git for Windows' system config where users expect it, 2021-06-22), I moved the location of Git for Windows' system config and system Git attributes file to the top-level `/etc/` directory (because it is a much more obvious location than, say, `/mingw64/etc/`). The patch relied on a very specific scenario that the newly-supported Windows/ARM64 builds of `git.exe` fails to fall into. So let's broaden the condition a bit, so that Windows/ARM64 builds also use that location (instead of the even more obscure `/clangarm64/etc/` directory). This fixes git-for-windows#5431. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just as in b64d78a (max_tree_depth: lower it for MSVC to avoid stack overflows, 2023-11-01), I encountered the same problem with the clang builds on Windows/ARM64. The symptom is an exit code 127 when t6700 tries to verify that `git archive big` fails. This exit code is reserved on Unix/Linux to mean "command not found". Unfortunately in this case, it is the fall-back chosen by Cygwin's `pinfo::status_exit()` method when encountering the NSTATUS `STATUS_STACK_OVERFLOW`, see https://github.com/cygwin/cygwin/blob/cygwin-3.6.1/winsup/cygwin/pinfo.cc#L171 I verified manually that the stack overflow always happens somewhere around tree depth 1403, therefore 1280 should be a safe bound in these instances. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The GitHub's CI workflow uses 'actions/checkout@v4' to checkout the repository. This action defaults to using the GitHub REST API to obtain the repository if the `git` executable isn't available. The step to build Git in the GitHub workflow can be summarized as: ... - uses: actions/checkout@v4 #1 - run: ci/install-dependencies.sh #2 ... - run: sudo --preserve-env --set-home --user=builder ci/run-build-and-tests.sh #3 ... Step #1, clones the repository, since the `git` executable isn't present at this step, it uses GitHub's REST API to obtain a tar of the repository. Step #2, installs all dependencies, which includes the `git` executable. Step #3, sets up the build, which includes setting up meson in the meson job. At this point the `git` executable is present. This means while the `git` executable is present, the repository doesn't contain the '.git' folder. To keep both the CI's (GitLab and GitHub) behavior consistent and to ensure that the build is performed on a real-world scenario, install `git` before the repository is checked out. This ensures that 'actions/checkout@v4' will clone the repository instead of using a tarball. We also update the package cache while installing `git`, this is because some distros will fail to locate the package without updating the cache. Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In Meson, included subdirs export their variables to top level Meson builds. In 'contrib/coccinelle/meson.build', we define two such variables `sources` and `headers`. While these variables are specific to the checks in the 'contrib/coccinelle/' directory, they also pollute the top level 'meson.build'. Rename them to be more specific, this ensures that they aren't mistakenly used in the upper levels and avoid variable name collisions. While here, change the empty list denotation to be consistent with other places. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Meson build for coccinelle static analysis lists all headers to analyse. Due to the way Meson exports variables between subdirs, this variable is also available in the root Meson build. An upcoming commit, will add a new check complimenting 'hdr-check' in the Makefile. This would require the list of headers. So move the 'coccinelle_headers' to the root Meson build and rename it to 'headers', remove the root path being appended to each header and retain that in the coccinelle Meson build since it is specific to the coccinelle build. Also move the 'third_party_sources' variable to the root Meson build since it is also a dependency for the 'headers' variable. This also makes it easier to understand as the variable is now propagated from the top level to the bottom. While 'headers_to_check' is only computed when we have a repository and the 'git' executable is present, the variable itself is exposed as an empty array. This allows dependencies in upcoming commits to simply check for length of the array and not worry about dependencies required to actually populate the array. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'third_party_sources' variable was moved to the root 'meson.build' file in the previous commit. The variable is actually used to exclude third party sources, so rename it accordingly to 'third_party_excludes' to avoid confusion. While here, remove a duplicate from the list. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Makefile supports a target called 'hdr-check', which checks if individual header files can be independently compiled. Let's port this functionality to Meson, our new build system too. The implementation resembles that of the Makefile and provides the same check. Since meson builds are out-of-tree, header dependencies are not automatically met. So unlike the Makefile version, we also need to add the required dependencies. Also add the 'xdiff/' dir to the list of 'third_party_sources' as those headers must be skipped from the checks too. This also skips the folder from the 'coccinelle' checks, this is okay, since this code is an external dependency. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'hdr-check' target in Meson and makefile is used to check if headers can be compiled individually. The naming however isn't readable as 'hdr' is not a common shortforme for 'header', neither is it an abbreviation. Let's introduce 'check-headers' as an alternative target for 'hdr-check' and add a `TODO` to deprecate the latter after 2 releases. Since this is an internal tool, we can use a shorter deprecation cycle. Change existing usage of 'hdr-check' in 'ci/run-static-analysis.sh' to also use 'check-headers'. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is repetitive logic. We either want to use some -lc function, or if it is not available we define it as -DNO_XXX and usually (but not always) provide some custom compatibility impl instead. Checking the intent of each block when reading through the file is slow and not very DRY. Switch to taking an array of checkable functions instead. Not all functions are straightforward to move, since different macro prefixes are used. Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is deprecated and removed in SUS v3 / POSIX 2001, so various systems may not include it. Solaris, in particular, carefully refrains from defining it except inside of a maze of `#ifdef` to make sure you have kept your nose clean and only used it in code that *targets* SUS v2 or earlier. config.mak.uname defines this automatically, though only for QNX. Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Solaris, sys/sysinfo.h is a completely different file and doesn't resemble the linux file at all. There is also a sysinfo() function, but it takes a totally different call signature, which asks for: - the field you wish to receive - a `char *buf` to copy the data to and is very useful IFF you want to know, say, the hardware provider. Or, get *specific* fields from uname(2). https://docs.oracle.com/cd/E86824_01/html/E54765/sysinfo-2.html It is surely possible to do this manually via `sysconf(3)` without the nice API. I can't find anything more direct. Either way, I'm not very attached to Solaris, so someone who cares can add it. Either way, it's wrong to assume that sysinfo.h contains what we are looking for. Check that sysinfo.h defines the struct we actually utilize in builtins/gc.c, which will correctly fail on systems that don't have it. Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
As evidenced in config.mak.uname and configure.ac, there are various possible scenarios where these libraries are default-enabled in the build, which mainly boils down to: SunOS. -lresolv is simply not the only library that, when it exists, probably needs to be linked to for networking. Check for and add -lnsl -lsocket as well. Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nowhere in the codebase do we otherwise check for strerror. Nowhere in the codebase do we make use of -DNO_STRERROR. `strerror` is not a networking function at all. We do utilize `hstrerror` though, which is a networking function we should have been checking here. Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
…pat impls These are added in the Makefile, but not in meson. They probably won't work well on systems without them. CMake adds them, but only on non-Windows. Actually, it only performs compiler checks for hstrerror, but excludes that check on Windows with the note that it is "incompatible with the Windows build". This seems to be misleading -- it is not incompatible, it simply doesn't exist. Still, the compat version should not be used. I interpret this cmake logic to mean we shouldn't even be checking for symbol availability on Windows. In addition to making it simple to add compat definitions, this also probably shaves off a second or two of configure time on Windows as no compiler check needs to be performed. Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many of our benchmarks operate on a user-defined repository that we copy over before running the benchmarked logic. To keep unintentional side effects caused by on-disk state at bay we skip copying some files. This includes for example hooks, but also the repo's configuration. It is quite sensible to not copy over the configuration, as it is quite easy to inadvertently carry over configuration that may significantly impact the performance measurements. But we cannot fully ignore the configuration either, as it may contain information about the repository format. This will cause failures when for example using a repository with SHA256 object format or the reftable ref format. Fix the issue by parsing the reference and object formats from the source repository and passing them to git-init(1). Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our benchmarks use a couple of Perl scripts to compute results. These Perl scripts get executed directly, and as the shebang is hardcoded to "/usr/bin/perl" this will fail on any system where the Perl interpreter is located in a different path. Our build infrastructure already lets users configure the location of Perl, which ultimately gets written into the GIT-BUILD-OPTIONS file. This file is being sourced by "test-lib.sh", and consequently we already have the "PERL_PATH" variable available that contains its configured location. Use "PERL_PATH" to execute Perl scripts, which makes them work on more esoteric systems like NixOS. Furthermore, adapt the shebang to use env(1) to execute Perl so that users who have Perl in PATH, but in a non-standard location can execute the script directly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "perf-lib.sh" script is sourced by all of our benchmarking suites to
make available common infrastructure. The script assumes that build and
source directory are the same, which works for our Makefile. But the
assumption breaks with both CMake and Meson, where the build directory
can be located in an arbitrary place.
Adapt the script so that it works with out-of-tree builds. Most
importantly, this requires us to figure out the location of the build
directory:
- When running benchmarks via our Makefile the build directory is the
same as the source directory. We already know to derive the test
directory ("t/") via `$(pwd)/..`, which works because we chdir into
"t/perf" before executing benchmarks. We can thus derive the build
directory by appending another "/.." to that path.
- When running benchmarks via Meson the build directory is located at
an arbitrary location. The build system thus has to make the path
known by exporting the `GIT_BUILD_DIR` environment variable.
This change prepares us for wiring up benchmarks in Meson.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Wire up benchmarks in Meson. The setup is mostly the same as how we wire
up our tests. The only difference is that benchmarks get wired up via
the `benchmark()` option instead of via `test()`, which gives them a bit
of special treatment:
- Benchmarks never run in parallel.
- Benchmarks aren't run by default when tests are executed.
- Meson does not inject the `MALLOC_PERTURB` environment variable.
Using benchmarks is quite simple:
```
$ meson setup build
# Run all benchmarks.
$ meson test -C build --benchmark
# Run a specific benchmark.
$ meson test -C build --benchmark p0000-*
```
Other than that the usual command line arguments accepted when running
tests are also accepted when running benchmarks.
Note that the benchmarking target is somewhat limited because it will
only run benchmarks for the current build. Other use cases, like running
benchmarks against multiple different versions of Git, are not currently
supported. Users should continue to use "t/perf/run" for those use
cases. The script should get extended at one point in time to support
Meson, but this is outside of the scope of this series.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Wire up a couple of benchmarking options that we end up writing into our "GIT-BUILD-OPTIONS" file. These options allow users to control how exactly benchmarks are executed. Note that neither `GIT_PERF_MAKE_COMMAND` nor `GIT_PERF_MAKE_OPTS` are exposed as a build option. Those options are used by "t/perf/run", which is not used by Meson. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update to arm64 Windows port. * js/windows-arm64: max_tree_depth: lower it for clangarm64 on Windows mingw(arm64): do move the `/etc/git*` location msvc: do handle builds on Windows/ARM64 mingw: do not use nedmalloc on Windows/ARM64 config.mak.uname: add support for clangarm64 bswap.h: add support for built-in bswap functions
The build procedure based on Meson learned to drive the benchmarking tests. * ps/meson-build-perf-bench: meson: wire up benchmarking options meson: wire up benchmarks t/perf: fix benchmarks with out-of-tree builds t/perf: use configured PERL_PATH t/perf: fix benchmarks with alternate repo formats
Code clean-up for meson-based build infrastructure. * es/meson-cleanup: meson: only check for missing networking syms on non-Windows; add compat impls meson: fix typo in function check that prevented checking for hstrerror meson: add a couple missing networking dependencies meson: do a full usage-based compile check for sysinfo meson: check for getpagesize before using it meson: simplify and parameterize various standard function checks
Add an equivalent to "make hdr-check" target to meson based builds. * kn/meson-hdr-check: makefile/meson: add 'check-headers' as alias for 'hdr-check' meson: add support for 'hdr-check' meson: rename 'third_party_sources' to 'third_party_excludes' meson: move headers definition from 'contrib/coccinelle' coccinelle: meson: rename variables to be more specific ci/github: install git before checking out the repository
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )