summaryrefslogtreecommitdiffstats
path: root/contrib/buildsystems (follow)
Commit message (Collapse)AuthorAgeFilesLines
* GIT-BUILD-OPTIONS: wire up NO_GITWEB optionPatrick Steinhardt2024-12-271-0/+1
| | | | | | | | | | | | | | | | | | | | Building our "gitweb" interface is optional in our Makefile and in Meson and not wired up at all with CMake, but disabling it causes a couple of tests in the t950* range that pull in "t/lib-gitweb.sh". This is because the test library knows to execute gitweb-tests based on whether or not Perl is available, but we may have Perl available and still end up not building gitweb e.g. with `make test NO_GITWEB=YesPlease`. Fix this issue by wiring up a new "NO_GITWEB" build option so that we can skip these tests in case gitweb is not built. Note that this new build option requires us to move the configuration of GIT-BUILD-OPTIONS to a later point in our Meson build instructions. But as that file is only consumed by our tests at runtime this change does not cause any issues. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* GIT-BUILD-OPTIONS: sort variables alphabeticallyPatrick Steinhardt2024-12-271-35/+35
| | | | | | | | | The variables declared and substituted in GIT-BUILD-OPTIONS are not ordered in any obvious way. Sort them alphabetically so that it becomes obvious where new variables should go. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake/vcxproj: stop special-casing `remote-ext`Johannes Schindelin2024-12-171-1/+1
| | | | | | | | | | | | | | | | | | | When the `vcxproj` target was introduced in `config.mak.uname` to allow building Git with the Visual C toolchain, the `git remote-ext` command was always executed in its dashed form. Therefore, it was impossible to pass the test suite unless that command existed in its dashed form, and we had to special-case this. Later, when the `vcxproj` target got out of fashion because Visual Studio gained native support for CMake builds, this special-casing was copied without questioning it. But as of 675df192c5f (transport-helper: do not run git-remote-ext etc. in dashed form, 2020-08-26), the reason for this special-casing no longer exists. So let's just drop it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: put the Perl modules into the correct location againJohannes Schindelin2024-12-171-0/+4
| | | | | | | | | | | | | | | | | | | In ccfba9e0c45 (Makefile: use "generate-perl.sh" to massage Perl library, 2024-12-06), the previous strategy (which avoided spawning a shell script to transform the files) was replaced by the same `generate-perl.sh` invocation as for the Makefile-based build. The only difference is that now the transformation tries to handle the Perl modules in-place (which ends up in empty files because the same file is used as input and output via stdin/stdout redirection), and the Perl script cannot find them anymore because they are not in the expected place. Let's put them into the expected place again, i.e. into `perl/build/lib/` instead of `perl/`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: use the correct file name for the Perl headerJohannes Schindelin2024-12-171-2/+2
| | | | | | | | | | | | | | In e4b488049a5 (Makefile: extract script to massage Perl scripts, 2024-12-06), the code was refactored that is used to transform the Perl scripts/modules to their final form. Even the CMake-based build was adjusted, but the change used the file name `PERL-HEADER` instead of the file name used by the Makefile-based build (same name but with the `GIT-` prefix). Let's adjust the former to the latter. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake(mergetools): better support for out-of-tree buildsJohannes Schindelin2024-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | In 7e0730c8baa (t: better support for out-of-tree builds, 2024-12-06) the strategy was changed from letting `t7609-mergetool--lib.sh` hard-code the directory where it expects to find the merge tools to hard-coding that value in the placeholder `@GIT_TEST_MERGE_TOOLS_DIR@` that is replaced during the build. However, likely due to a copy/paste mistake (and reviewers missed this, too), the CMake-based build was adjusted incorrectly, replacing that placeholder not with the path to the merge tools, but with a Boolean indicating whether to use a runtime-generated path prefix or not. Let's fix that, addressing this CMake-build's symptom: Initialized empty Git repository in D:/a/git/git/t/trash directory.t7609-mergetool--lib/.git/ ++ . true/vimdiff ./test-lib.sh: line 1021: true/vimdiff: No such file or directory Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: better support for out-of-tree builds follow-upJohannes Schindelin2024-12-171-0/+3
| | | | | | | | | | | | | | | | | | | | In 7e0730c8baa (t: better support for out-of-tree builds, 2024-12-06), the `bin-wrappers/` strategy was changed so that it no longer hard-codes the template directory to be `@BUILD_DIR@/templates/blt`, but instead interpolates the `@TEMPLATE_DIR@` placeholder during the build. However, this commit only adjusted the `Makefile`-based build. Let's adjust the CMake-based build as well. This fixes t0000.15 which would otherwise fail with: ++ echo ''\''t1234-verbose/err'\'' is not empty, it contains:' 't1234-verbose/err' is not empty, it contains: ++ cat t1234-verbose/err warning: templates not found in @TEMPLATE_DIR@ Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t: better support for out-of-tree buildsPatrick Steinhardt2024-12-061-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Our in-tree builds used by the Makefile use various different build directories scattered around different locations. The paths to those build directories have to be propagated to our tests such that they can find the contained files. This is done via a mixture of hardcoded paths in our test library and injected variables in our bin-wrappers or "GIT-BUILD-OPTIONS". The latter two mechanisms are preferable over using hardcoded paths. For one, we have all paths which are subject to change stored in a small set of central files instead of having the knowledge of build paths in many files. And second, it allows build systems which build files elsewhere to adapt those paths based on their own needs. This is especially nice in the context of build systems that use out-of-tree builds like CMake or Meson. Remove hardcoded knowledge of build paths from our test library and move it into our bin-wrappers and "GIT-BUILD-OPTIONS". Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: simplify building of templatesPatrick Steinhardt2024-12-061-22/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we install Git we also install a set of default templates that both git-init(1) and git-clone(1) populate into our build directories. The way the pristine templates are laid out in our source directory is somewhat weird though: instead of reconstructing the actual directory hierarchy in "templates/", we represent directory separators with "--". The only reason I could come up with for why we have this is the "branches/" directory, which is supposed to be empty when installing it. And as Git famously doesn't store empty directories at all we have to work around this limitation. Now the thing is that the "branches/" directory is a leftover to how branches used to be stored in the dark ages. gitrepository-layout(5) lists this directory as "slightly deprecated", which I would claim is a strong understatement. I have never encountered anybody using it today and would be surprised if it even works as expected. So having the "--" hack in place for an item that is basically unused, unmaintained and deprecated doesn't only feel unreasonable, but installing that entry by default may also cause confusion for users that do not know what this is supposed to be in the first place. Remove this directory from our templates and, now that we do not require the workaround anymore, restructure the templates to form a proper hierarchy. This makes it way easier for build systems to install these templates into place. We should likely think about removing support for "branch/" altogether, but that is outside of the scope of this patch series. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: write absolute program path into bin-wrappersPatrick Steinhardt2024-12-061-3/+3
| | | | | | | | Write the absolute program path into our bin-wrappers. This allows us to simplify the Meson build instructions we are about to introduce a bit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: allow "bin-wrappers/" directory to existPatrick Steinhardt2024-12-061-3/+3
| | | | | | | | | | | | | | The "bin-wrappers/" directory gets created by our build system and is populated with one script for each of our binaries. There isn't anything inherently wrong with the current layout, but it is somewhat hard to adapt for out-of-tree build systems. Adapt the layout such that our "bin-wrappers/" directory always exists and contains our "wrap-for-bin.sh" script to make things a little bit easier for subsequent steps. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: refactor generators to be PWD-independentPatrick Steinhardt2024-12-061-9/+10
| | | | | | | | | | | | | We have multiple scripts that generate headers from other data. All of these scripts have the assumption built-in that they are executed in the current source directory, which makes them a bit unwieldy to use during out-of-tree builds. Refactor them to instead take the source directory as well as the output file as arguments. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: extract script to massage Python scriptsPatrick Steinhardt2024-12-061-4/+11
| | | | | | | | | | | | | | | | Extract a script that massages Python scripts. This provides a couple of benefits: - The build logic is deduplicated across Make, CMake and Meson. - CMake learns to rewrite scripts as-needed at build time instead of only writing them at configure time. Furthermore, we will use this script when introducing Meson to deduplicate the logic across build systems. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: extract script to massage Shell scriptsPatrick Steinhardt2024-12-061-11/+20
| | | | | | | | Same as in the preceding commits, extract a script that allows us to unify how we massage shell scripts. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: use "generate-perl.sh" to massage Perl libraryPatrick Steinhardt2024-12-061-14/+9
| | | | | | | | | | | | | | | | Extend "generate-perl.sh" such that it knows to also massage the Perl library files. There are two major differences: - We do not read in the Perl header. This is handled by matching on whether or not we have a Perl shebang. - We substitute some more variables, which we read in via our GIT-BUILD-OPTIONS. Adapt both our Makefile and the CMake build instructions to use this. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: extract script to massage Perl scriptsPatrick Steinhardt2024-12-061-5/+27
| | | | | | | | | Extract the script to inject various build-time parameters into our Perl scripts into a standalone script. This is done such that we can reuse it in other build systems. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: consistently use PERL_PATHPatrick Steinhardt2024-12-061-1/+1
| | | | | | | | | | When injecting the Perl path into our scripts we sometimes use '@PERL@' while we othertimes use '@PERL_PATH@'. Refactor the code use the latter consistently, which makes it easier to reuse the same logic for multiple scripts. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: generate "git.rc" via GIT-VERSION-GENPatrick Steinhardt2024-12-061-6/+13
| | | | | | | | | | | | | The "git.rc" is used on Windows to embed information like the project name and version into the resulting executables. As such we need to inject the version information, which we do by using preprocessor defines. The logic to do so is non-trivial and needs to be kept in sync with the different build systems. Refactor the logic so that we generate "git.rc" via `GIT-VERSION-GEN`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: propagate Git version via generated headerPatrick Steinhardt2024-12-061-4/+12
| | | | | | | | | | | | | We set up a couple of preprocessor macros when compiling Git that propagate the version that Git was built from to `git version` et al. The way this is set up makes it harder than necessary to reuse the infrastructure across the different build systems. Refactor this such that we generate a "version-def.h" header via `GIT-VERSION-GEN` instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: refactor GIT-VERSION-GEN to be reusablePatrick Steinhardt2024-12-062-17/+7
| | | | | | | | | | | | | | | | | | | | | | | Our "GIT-VERSION-GEN" script always writes the "GIT-VERSION-FILE" into the current directory, where the expectation is that it should exist in the source directory. But other build systems that support out-of-tree builds may not want to do that to keep the source directory pristine, even though CMake currently doesn't care. Refactor the script such that it won't write the "GIT-VERSION-FILE" directly anymore, but instead knows to replace @PLACEHOLDERS@ in an arbitrary input file. This allows us to simplify the logic in CMake to determine the project version, but can also be reused later on in order to generate other files that need to contain version information like our "git.rc" file. While at it, change the format of the version file by removing the spaces around the equals sign. Like this we can continue to include the file in our Makefiles, but can also start to source it in shell scripts in subsequent steps. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: consistently use @PLACEHOLDER@ to substitutePatrick Steinhardt2024-12-061-17/+17
| | | | | | | | | | | | | | | | | | | | We have a bunch of placeholders in our scripts that we replace at build time, for example by using sed(1). These placeholders come in three different formats: @PLACEHOLDER@, @@PLACEHOLDER@@ and ++PLACEHOLDER++. Next to being inconsistent it also creates a bit of a problem with CMake, which only supports the first syntax in its `configure_file()` function. To work around that we instead manually replace placeholders via string operations, which is a hassle and removes safeguards that CMake has to verify that we didn't forget to replace any placeholders. Besides that, other build systems like Meson also support the CMake syntax. Unify our codebase to consistently use the syntax supported by such build systems. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile: use common template for GIT-BUILD-OPTIONSPatrick Steinhardt2024-12-061-19/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "GIT-BUILD-OPTIONS" file is generated by our build systems to propagate built-in features and paths to our tests. The generation is done ad-hoc, where both our Makefile and the CMake build instructions simply echo a bunch of strings into the file. This makes it very hard to figure out what variables are expected to exist and what format they have, and the written variables can easily get out of sync between build systems. Introduce a new "GIT-BUILD-OPTIONS.in" template to address this issue. This has multiple advantages: - It demonstrates which built options exist in the first place. - It can serve as a spot to document the build options. - Some build systems complain when not all variables could be substituted, alerting us of mismatches. Others don't, but if we forgot to substitute such variables we now have a bogus string that will likely cause our tests to fail, if they have any meaning in the first place. Backfill values that we didn't yet set in our CMake build instructions. While at it, remove the `SUPPORTS_SIMPLE_IPC` variable that we only set up in CMake as it isn't used anywhere. This change requires us to adapt the setup of TEST_OUTPUT_DIRECTORY in "test-lib.sh" such that it does not get overwritten after sourcing when it has been set up via the environment. This is the only instance I could find where we rely on ordering on variables. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: use verbatim arguments when invoking clar commandsPatrick Steinhardt2024-11-181-2/+4
| | | | | | | | | Pass the VERBATIM option to `add_custom_command()`. Like this, all arguments to the commands will be escaped properly for the build tool so that the invoked command receives each argument unchanged. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: use SH_EXE to execute clar scriptsPatrick Steinhardt2024-11-181-3/+6
| | | | | | | | | | | | | | | | | | | | | In 30bf9f0aaa (cmake: set up proper dependencies for generated clar headers, 2024-10-21), we have deduplicated the logic to generate our clar headers by reusing the same scripts that our Makefile does. Despite the deduplication, this refactoring also made us rebuild the headers in case the source files change, which didn't happen previously. The commit also introduced an issue though: we execute the scripts directly, so when the host does not have "/bin/sh" available they will fail. This is for example the case on Windows when importing the CMake project into Microsoft Visual Studio. Address the issue by invoking the scripts with `SH_EXE`, which contains the discovered path of the shell interpreter. While at it, wrap the overly long lines in the CMake build instructions. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t/unit-tests: convert "clar-generate.awk" into a shell scriptPatrick Steinhardt2024-11-181-2/+5
| | | | | | | | | | | | Convert "clar-generate.awk" into a shell script that invokes awk(1). This allows us to avoid the shell redirect in the build system, which may otherwise be a problem with build systems on platforms that use a different shell. While at it, wrap the overly long lines in the CMake build instructions. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ps/upgrade-clar'Junio C Hamano2024-11-081-39/+13
|\ | | | | | | | | | | | | | | | | | | | | Buildfix and upgrade of Clar to a newer version. * ps/upgrade-clar: cmake: set up proper dependencies for generated clar headers cmake: fix compilation of clar-based unit tests Makefile: extract script to generate clar declarations Makefile: adjust sed command for generating "clar-decls.h" t/unit-tests: update clar to 206accb
| * cmake: set up proper dependencies for generated clar headersPatrick Steinhardt2024-10-211-38/+12
| | | | | | | | | | | | | | | | | | | | The auto-generated headers used by clar are written at configure time and thus do not get regenerated automatically. Refactor the build recipes such that we use custom commands instead, which also has the benefit that we can reuse the same infrastructure as our Makefile. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com>
| * cmake: fix compilation of clar-based unit testsPatrick Steinhardt2024-10-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compilation of clar-based unit tests is broken because we do not add the binary directory into which we generate the "clar-decls.h" and "clar.suite" files as include directories. Instead, we accidentally set up the source directory as include directory. Fix this by including the binary directory instead of the source directory. Furthermore, set up the include directories as PUBLIC instead of PRIVATE such that they propagate from "unit-tests.lib" to the "unit-tests" executable, which needs to include the same directory. Reported-by: Ed Reel <edreel@gmail.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com>
* | t/test-lib: wire up NO_ICONV prerequisitePatrick Steinhardt2024-10-161-0/+6
|/ | | | | | | | | | | | | | | | | | | | The iconv library is used by Git to reencode files, commit messages and other things. As such it is a rather integral part, but given that many platforms nowadays use UTF-8 everywhere you can live without support for reencoding in many situations. It is thus optional to build Git with iconv, and some of our platforms wired up in "config.mak.uname" disable it. But while we support building without it, running our test suite with "NO_ICONV=Yes" causes many test failures. Wire up a new test prerequisite ICONV that gets populated via our GIT-BUILD-OPTIONS. Annotate failing tests accordingly. Note that this commit does not do a deep dive into every single test to assess whether the failure is expected or not. Most of the tests do smell like the expected kind of failure though. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com>
* cmake: generalize the handling of the `UNIT_TEST_OBJS` listJohannes Schindelin2024-09-191-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a15d4465a991 (cmake: also build unit tests, 2023-09-25), I accommodated the CMake definition. Seeing that a `UNIT_TEST_OBJS` list was introduced that was built by transforming the `UNIT_TEST_PROGRAMS` list and then adding a single, hard-coded file ("t/unit-tests/test-lib.c"), I decided to hard-code that in the CMake definition, too. The reason why I hard-coded it instead of imitating the `parse_makefile_for_sources()` paradigm that was used elsewhere when using the `Makefile` as source of truth for given lists of files: This function expects _only_ hard-coded values, and that transformed `UNIT_TEST_PROGRAMS` list complicated everything. In 872721538c26 (cmake: fix build of `t-oidtree`, 2024-07-12), I accommodated the CMake definition again, after seeing that the `UNIT_TEST_OBJS` was still defined via that transformed list but now appending _two_ hard-coded files ("t/unit-tests/lib-oid.c" joined the fray). In 428672a3b16 (Makefile: stop listing test library objects twice, 2024-09-16), the `Makefile` was changed so that `UNIT_TEST_OBJS` is finally only constructed using hard-coded file names just like the other `*_OBJS` variables. I missed that and therefore did not adjust the CMake definition. Besides, the code was working, so there was no real need to adjust it. With a4f50bb1e9b (t/unit-tests: introduce reftable library, 2024-09-16), however, the `UNIT_TEST_OBJS` list became a trio, and the CMake definition has to be adjusted again. Now that we can use the `parse_makefile_for_sources()` function without many complications, let's do that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: stop looking for `REFTABLE_TEST_OBJS` in the MakefileJohannes Schindelin2024-09-191-5/+1
| | | | | | | | | | As of 15e29ea1c648 (t: move reftable/stack_test.c to the unit testing framework, 2024-09-08), the reftable tests are no longer part of `test-tool.exe`, so let's stop looking for those lines that are no longer in the `Makefile`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: rename clar-related variables to avoid confusionJohannes Schindelin2024-09-191-6/+6
| | | | | | | | | | In c3de556a841f (Makefile: rename clar-related variables to avoid confusion, 2024-09-10) some `Makefile` variables were renamed that were partially used by the CMake definition. Adapt the latter to the new lay of the land. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* clar: add CMake supportJohannes Schindelin2024-09-041-0/+53
| | | | | | | | | | Now that we're using `clar` as powerful test framework, we have to adjust the Visual C build (read: the CMake definition) to be able to handle that, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: fix build of `t-oidtree`Johannes Schindelin2024-07-121-1/+2
| | | | | | | | | | | | When the `oidtree` test helper was turned into a unit test, a new `lib-oid` source file was added as dependency. This was only done in the Makefile so far, but also needs to be done in the CMake definition. This is a companion of ed548408723d (t/: migrate helper/test-oidtree.c to unit-tests/t-oidtree.c, 2024-06-08). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: let `test-tool` run the unit tests, tooJohannes Schindelin2024-05-061-1/+2
| | | | | | | | | | | | The `test-tool` recently learned to run the unit tests. To this end, it needs to link with `test-lib.c`, which was done in the `Makefile`, and this patch does it in the CMake definition, too. This is a companion of 44400f58407e (t0080: turn t-basic unit test into a helper, 2024-02-02). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/doc-unit-tests-with-cmake'Junio C Hamano2023-12-101-4/+34
|\ | | | | | | | | | | | | | | | | | | | | | | | | Update the base topic to work with CMake builds. * js/doc-unit-tests-with-cmake: cmake: handle also unit tests cmake: use test names instead of full paths cmake: fix typo in variable name artifacts-tar: when including `.dll` files, don't forget the unit-tests unit-tests: do show relative file paths unit-tests: do not mistake `.pdb` files for being executable cmake: also build unit tests
| * cmake: handle also unit testsJohannes Schindelin2023-11-101-0/+11
| | | | | | | | | | | | | | | | | | The unit tests should also be available e.g. in Visual Studio's Test Explorer when configuring Git's source code via CMake. Suggested-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * cmake: use test names instead of full pathsJohannes Schindelin2023-11-101-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The primary purpose of Git's CMake definition is to allow developing Git in Visual Studio. As part of that, the CTest feature allows running individual test scripts conveniently in Visual Studio's Test Explorer. However, this Test Explorer's design targets object-oriented languages and therefore expects the test names in the form `<namespace>.<class>.<testname>`. And since we specify the full path of the test scripts instead, including the ugly `/.././t/` part, these dots confuse the Test Explorer and it uses a large part of the path as "namespace". Let's just use `t.suite.<name>` instead. This presents the tests in Visual Studio's Test Explorer in the following form by default (i.e. unless the user changes the view via the "Group by" menu): ◢ ◈ git ◢ ◈ t ◢ ◈ suite ◈ t0000-basic ◈ t0001-init ◈ t0002-gitfile [...] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * cmake: fix typo in variable nameJohannes Schindelin2023-11-101-2/+2
| | | | | | | | | | Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * cmake: also build unit testsJohannes Schindelin2023-11-101-0/+18
| | | | | | | | | | | | | | | | A new, better way to run unit tests was just added to Git. This adds support for building those unit tests via CMake. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ds/maintenance-on-windows-fix'Junio C Hamano2023-08-153-2/+12
|\ \ | | | | | | | | | | | | | | | | | | | | | Windows updates. * ds/maintenance-on-windows-fix: git maintenance: avoid console window in scheduled tasks on Windows win32: add a helper to run `git.exe` without a foreground window
| * | win32: add a helper to run `git.exe` without a foreground windowJohannes Schindelin2023-08-093-2/+12
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows, there are two kinds of executables, console ones and non-console ones. Git's executables are all console ones. When launching the former e.g. in a scheduled task, a CMD window pops up. This is not what we want for the tasks installed via the `git maintenance` command. To work around this, let's introduce `headless-git.exe`, which is a non-console program that does _not_ pop up any window. All it does is to re-launch `git.exe`, suppressing that console window, passing through all command-line arguments as-are. Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Helped-by: Yuyi Wang <Strawberry_Str@hotmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* / cache.h: remove this no-longer-used headerElijah Newren2023-06-211-1/+1
|/ | | | | | | | | | | | | | | Since this header showed up in some places besides just #include statements, update/clean-up/remove those other places as well. Note that compat/fsmonitor/fsm-path-utils-darwin.c previously got away with violating the rule that all files must start with an include of git-compat-util.h (or a short-list of alternate headers that happen to include it first). This change exposed the violation and caused it to stop building correctly; fix it by having it include git-compat-util.h first, as per policy. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Makefile & test-tool: replace "DC_SHA1" variable with a "define"Ævar Arnfjörð Bjarmason2022-11-081-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Address the root cause of technical debt we've been carrying since sha1collisiondetection was made the default in [1]. In a preceding commit we narrowly fixed a bug where the "DC_SHA1" variable would be unset (in combination with "NO_APPLE_COMMON_CRYPTO=" on OSX), even though we had the sha1collisiondetection library enabled. But the only reason we needed to have such a user-exposed knob went away with [1], and it's been doing nothing useful since then. We don't care if you define DC_SHA1=*, we only care that you don't ask for any other SHA-1 implementation. If it turns out that you didn't, we'll use sha1collisiondetection, whether you had "DC_SHA1" set or not. As a result of this being confusing we had e.g. [2] for cmake and the recent [3] for ci/lib.sh setting "DC_SHA1" explicitly, even though this was always a NOOP. A much simpler way to do this is to stop having the Makefile and CMakeLists.txt set "DC_SHA1" to be picked up by the test-lib.sh, let's instead add a trivial "test-tool sha1-is-sha1dc". It returns zero if we're using sha1collisiondetection, non-zero otherwise. 1. e6b07da2780 (Makefile: make DC_SHA1 the default, 2017-03-17) 2. c4b2f41b5f5 (cmake: support for testing git with ctest, 2020-06-26) 3. 1ad5c3df35a (ci: use DC_SHA1=YesPlease on osx-clang job for CI, 2022-10-20) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com>
* Merge branch 'js/cmake-updates'Junio C Hamano2022-10-271-8/+8
|\ | | | | | | | | | | | | | | | | | | | | Update to build procedure with VS using CMake/CTest. * js/cmake-updates: cmake: increase time-out for a long-running test cmake: avoid editing t/test-lib.sh add -p: avoid ambiguous signed/unsigned comparison cmake: copy the merge tools for testing cmake: make it easier to diagnose regressions in CTest runs
| * cmake: increase time-out for a long-running testJohannes Schindelin2022-10-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As suggested in https://github.com/git-for-windows/git/issues/3966#issuecomment-1221264238, t7112 can run for well over one hour, which seems to be the default maximum run time at least when running CTest-based tests in Visual Studio. Let's increase the time-out as a stop gap to unblock developers wishing to run Git's test suite in Visual Studio. Note: The actual run time is highly dependent on the circumstances. For example, in Git's CI runs, the Windows-based tests typically take a bit over 5 minutes to run. CI runs have the added benefit that Windows Defender (the common anti-malware scanner on Windows) is turned off, something many developers are not at liberty to do on their work stations. When Defender is turned on, even on this developer's high-end Ryzen system, t7112 takes over 15 minutes to run. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * cmake: avoid editing t/test-lib.shJohannes Schindelin2022-10-191-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 7f5397a07c6c (cmake: support for testing git when building out of the source tree, 2020-06-26), we implemented support for running Git's test scripts even after building Git in a different directory than the source directory. The way we did this was to edit the file `t/test-lib.sh` to override `GIT_BUILD_DIR` to point somewhere else than the parent of the `t/` directory. This is unideal because it always leaves a tracked file marked as modified, and it is all too easy to commit that change by mistake. Let's change the strategy by teaching `t/test-lib.sh` to detect the presence of a file called `GIT-BUILD-DIR` in the source directory. If it exists, the contents are interpreted as the location to the _actual_ build directory. We then write this file as part of the CTest definition. To support building Git via a regular `make` invocation after building it using CMake, we ensure that the `GIT-BUILD-DIR` file is deleted (for convenience, this is done as part of the Makefile rule that is already run with every `make` invocation to ensure that `GIT-BUILD-OPTIONS` is up to date). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * cmake: copy the merge tools for testingJohannes Schindelin2022-10-191-1/+2
| | | | | | | | | | | | | | | | | | Even when running the tests via CTest, t7609 and t7610 rely on more than only a few mergetools to be copied to the build directory. Let's make it so. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * cmake: make it easier to diagnose regressions in CTest runsJohannes Schindelin2022-10-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a test script fails in Git's test suite, the usual course of action is to re-run it using options to increase the verbosity of the output, e.g. `-v` and `-x`. Like in Git's CI runs, when running the tests in Visual Studio via the CTest route, it is cumbersome or at least requires a very unintuitive approach to pass options to the test scripts: the CMakeLists.txt file would have to be modified, passing the desired options to _all_ test scripts, and then the CMake Cache would have to be reconfigured before running the test in question individually. Unintuitive at best, and opposite to the niceties IDE users expect. So let's just pass those options by default: This will not clutter any output window but the log that is written to a log file will have information necessary to figure out test failures. While at it, also imitate what the Windows jobs in Git's CI runs do to accelerate running the test scripts: pass the `--no-bin-wrappers` and `--no-chain-lint` options. This makes the test runs noticeably faster because the `bin-wrappers/` scripts as well as the `chain-lint` code make heavy use of POSIX shell scripting, which is really, really slow on Windows due to the need to emulate POSIX behavior via the MSYS2 runtime. In a test by Eric Sunshine, it added two minutes (!) just to perform the chain-lint task. The idea of adding a CMake config option (á la `GIT_TEST_OPTS`) was considered during the development of this patch, but then dropped: such a setting is global, across _all_ tests, where e.g. `--run=...` would not make sense. Users wishing to override these new defaults are better advised running the test script manually, in a Git Bash, with full control over the command line. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ed/fsmonitor-on-networked-macos'Junio C Hamano2022-10-171-0/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default, use of fsmonitor on a repository on networked filesystem is disabled. Add knobs to make it workable on macOS. * ed/fsmonitor-on-networked-macos: fsmonitor: fix leak of warning message fsmonitor: add documentation for allowRemote and socketDir options fsmonitor: check for compatability before communicating with fsmonitor fsmonitor: deal with synthetic firmlinks on macOS fsmonitor: avoid socket location check if using hook fsmonitor: relocate socket file if .git directory is remote fsmonitor: refactor filesystem checks to common interface
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-18 11:57:12 +0100