summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2021-10-07Merge branch 'ab/sanitize-leak-ci' into ab/mark-leak-free-testsLibravatar Junio C Hamano1-0/+5
* ab/sanitize-leak-ci: tests: add a test mode for SANITIZE=leak, run it in CI Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS
2021-10-03Merge branch 'ab/make-compdb-fix'Libravatar Junio C Hamano1-0/+1
Build update. * ab/make-compdb-fix: Makefile: pass -Wno-pendantic under GENERATE_COMPILATION_DATABASE=yes
2021-10-03Merge branch 'ab/auto-depend-with-pedantic'Libravatar Junio C Hamano1-0/+1
Improve build procedure for developers. * ab/auto-depend-with-pedantic: Makefile: make COMPUTE_HEADER_DEPENDENCIES=auto work with DEVOPTS=pedantic
2021-10-03Merge branch 'ab/make-clean-depend-dirs'Libravatar Junio C Hamano1-1/+0
"make clean" has been updated to remove leftover .depend/ directories, even when it is not told to use them to compute header dependencies. * ab/make-clean-depend-dirs: Makefile: clean .depend dirs under COMPUTE_HEADER_DEPENDENCIES != yes
2021-09-27Makefile: pass -Wno-pendantic under GENERATE_COMPILATION_DATABASE=yesLibravatar Ævar Arnfjörð Bjarmason1-0/+1
The same bug fixed in the "COMPUTE_HEADER_DEPENDENCIES=auto" mode in the preceding commit was also present with "GENERATE_COMPILATION_DATABASE=yes". Let's fix it so it works again with "DEVOPTS=1". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Merge branch 'ab/http-drop-old-curl-plus'Libravatar Junio C Hamano1-9/+2
Conditional compilation around versions of libcURL has been straightened out. * ab/http-drop-old-curl-plus: http: don't hardcode the value of CURL_SOCKOPT_OK http: centralize the accounting of libcurl dependencies http: correct curl version check for CURLOPT_PINNEDPUBLICKEY http: correct version check for CURL_HTTP_VERSION_2 http: drop support for curl < 7.18.0 (again) Makefile: drop support for curl < 7.9.8 (again) INSTALL: mention that we need libcurl 7.19.4 or newer to build INSTALL: reword and copy-edit the "libcurl" section INSTALL: don't mention the "curl" executable at all
2021-09-23Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONSLibravatar Ævar Arnfjörð Bjarmason1-0/+5
When SANITIZE=leak is specified we'll now add a SANITIZE_LEAK flag to GIT-BUILD-OPTIONS, this can then be picked up by the test-lib.sh, which sets a SANITIZE_LEAK prerequisite. We can then skip specific tests that are known to fail under SANITIZE=leak, add one such annotation to t0004-unwritable.sh, which now passes under SANITIZE=leak. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22Makefile: make COMPUTE_HEADER_DEPENDENCIES=auto work with DEVOPTS=pedanticLibravatar Ævar Arnfjörð Bjarmason1-0/+1
The "COMPUTE_HEADER_DEPENDENCIES" feature added in [1] was extended to use auto-detection in [2], that "auto" detection has always piped STDERR to /dev/null, so any failures on compilers that didn't support these GCC flags would silently fall back to "COMPUTE_HEADER_DEPENDENCIES=no". Later when -Wpedantic support was added to DEVOPTS in [3] we started passing -Wpedantic in combination with -Werror to the compiler here. Note (to the pedantic): [3] actually passed "-pedantic", but it and "-Wpedantic" are synonyms. Turning on -Wpedantic in [3] broke the auto-detection, since this relies on compiling an empty program. GCC would loudly complain on STDERR: /dev/null:1: error: ISO C forbids an empty translation unit [-Werror=pedantic] cc1: note: unrecognized command-line option ‘-Wno-pedantic-ms-format’ may have been intended to silence earlier diagnostics cc1: all warnings being treated as errors But as that ended up in the "$(dep_check)" variable due to the "2>&1" in [2] we didn't see it. Then when [4] made DEVOPTS=pedantic the default specifying "DEVELOPER=1" would effectively set "COMPUTE_HEADER_DEPENDENCIES=no". To fix these issues let's unconditionally pass -Wno-pedantic after $(ALL_CFLAGS), we might get a -Wpedantic via config.mak.dev after, or the builder might specify it via CFLAGS. In either case this will undo current and future problems with -Wpedantic. I think it would make sense to simply remove the "2>&1", it would mean that anyone using a non-GCC-like compiler would get warnings under COMPUTE_HEADER_DEPENDENCIES=auto, e.g on AIX's xlc would emit: /opt/IBM/xlc/13.1.3/bin/.orig/xlc: 1501-208 (S) command option D is missing a subargument Non-zero 40 exit with COMPUTE_HEADER_DEPENDENCIES=auto, set it to "yes" or "no" to quiet auto-detect And on Solaris with SunCC: cc: Warning: Option -x passed to ld, if ld is invoked, ignored otherwise cc: refused to overwrite input file by output file: /dev/null cc: Warning: Option -x passed to ld, if ld is invoked, ignored otherwise cc: refused to overwrite input file by output file: /dev/null Non-zero 1 exit with COMPUTE_HEADER_DEPENDENCIES=auto, set it to "yes" or "no" to quiet auto-detect Both could be quieted by setting COMPUTE_HEADER_DEPENDENCIES=no explicitly, as suggested, but let's see if this'll fix it without emitting too much noise at those that aren't using "gcc" or "clang". 1. f2fabbf76e4 (Teach Makefile to check header dependencies, 2010-01-26) 2. 111ee18c31f (Makefile: Use computed header dependencies if the compiler supports it, 2011-08-18) 3. 729b3925ed9 (Makefile: add a DEVOPTS flag to get pedantic compilation, 2018-07-24) 4. 6a8cbc41bac (developer: enable pedantic by default, 2021-09-03) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-22Makefile: clean .depend dirs under COMPUTE_HEADER_DEPENDENCIES != yesLibravatar Ævar Arnfjörð Bjarmason1-1/+0
Fix a logic error in dfea575017d (Makefile: lazily compute header dependencies, 2010-01-26) where we'd make whether we cleaned the .depend dirs contingent on the currently configured COMPUTE_HEADER_DEPENDENCIES value. Before this running e.g.: make COMPUTE_HEADER_DEPENDENCIES=yes grep.o make COMPUTE_HEADER_DEPENDENCIES=no clean Would leave behind the .depend directory, now it'll be removed. Normally we'd need to use another variable, but in this case there's no other uses of $(dep_dirs), as opposed to $(dep_args) which is used as an argument to $(CC). So just deleting this line makes everything work correctly. See http://lore.kernel.org/git/xmqqmto48ufz.fsf@gitster.g for a report about this issue. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20Merge branch 'ab/make-tags-cleanup'Libravatar Junio C Hamano1-13/+19
Build clean-up for "make tags" and friends. * ab/make-tags-cleanup: Makefile: normalize clobbering & xargs for tags targets Makefile: remove "cscope.out", not "cscope*" in cscope.out target Makefile: don't use "FORCE" for tags targets Makefile: add QUIET_GEN to "cscope" target Makefile: move ".PHONY: cscope" near its target
2021-09-20Merge branch 'cb/pedantic-build-for-developers'Libravatar Junio C Hamano1-20/+2
Update the build procedure to use the "-pedantic" build when DEVELOPER makefile macro is in effect. * cb/pedantic-build-for-developers: developer: enable pedantic by default win32: allow building with pedantic mode enabled gettext: remove optional non-standard parens in N_() definition
2021-09-15Merge branch 'bs/install-strip'Libravatar Junio C Hamano1-3/+12
"make INSTALL_STRIP=-s install" allows the installation step to use "install -s" to strip the binaries as they get installed. * bs/install-strip: make: add INSTALL_STRIP option variable
2021-09-15Merge branch 'ab/no-more-check-bindir'Libravatar Junio C Hamano1-2/+1
Build simplification. * ab/no-more-check-bindir: Makefile: remove the check_bindir script
2021-09-13Makefile: drop support for curl < 7.9.8 (again)Libravatar Ævar Arnfjörð Bjarmason1-9/+2
In 1119a15b5c8 (http: drop support for curl < 7.11.1, 2021-07-30) support for curl versions older than 7.11.1 was removed, and we currently require at least version 7.19.4, see 644de29e220 (http: drop support for curl < 7.19.4, 2021-07-30). In those changes this Makefile-specific check added in 0890098780f (Decide whether to build http-push in the Makefile, 2005-11-18) was missed, now that we're never going to use such an ancient curl version we don't need to check that we have at least 7.9.8 here. I have no idea what in http-push.c broke on versions older than that. This does not impact "NO_CURL" setups, as this is in the "else" branch after that check. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-07Makefile: remove the check_bindir scriptLibravatar Ævar Arnfjörð Bjarmason1-2/+1
This script was added in f28ac70f48 (Move all dashed-form commands to libexecdir, 2007-11-28) when commands such as "git-add" lived in the bin directory, instead of the git exec directory. This notice helped someone incorrectly installing version v1.6.0 and later into a directory built for a pre-v1.6.0 git version. We're now long past the point where anyone who'd be helped by this warning is likely to be doing that, so let's just remove this check and warning to simplify the Makefile. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-05make: add INSTALL_STRIP option variableLibravatar Bagas Sanjaya1-3/+12
Add $(INSTALL_STRIP), which allows passing stripping options to $(INSTALL). For this to work, installing executables must be split to installing compiled binaries and scripts portions, since $(INSTALL_STRIP) is only meaningful to the former. Users can set this variable depending on their system. For example, Linux users can use `-s --strip-program=strip`, while FreeBSD users can simply set to `-s` and choose strip program with $STRIPBIN. [original outline by Đoàn Trần Công Danh] Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-03Merge branch 'sg/make-fix-ar-invocation'Libravatar Junio C Hamano1-2/+2
Build fix. * sg/make-fix-ar-invocation: Makefile: remove archives before manipulating them with 'ar'
2021-09-03developer: enable pedantic by defaultLibravatar Carlo Marcelo Arenas Belón1-2/+2
With the codebase firmly C99 compatible and most compilers supporting newer versions by default, it could help bring visibility to problems. Reverse the DEVOPTS=pedantic flag to provide a fallback for people stuck with gcc < 5 or some other compiler that either doesn't support this flag or has issues with it, and while at it also enable -Wpedantic which used to be controversial[1] when Apple compilers and clang had widely divergent version numbers. Ideally any compiler found to have issues with these flags will be added to an exception, and indeed, one was added to safely process windows headers that would use non standard print identifiers, but it is expected that more will be needed, so it could be considered a weather balloon. [1] https://lore.kernel.org/git/20181127100557.53891-1-carenas@gmail.com/ Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-03gettext: remove optional non-standard parens in N_() definitionLibravatar Ævar Arnfjörð Bjarmason1-19/+1
Remove the USE_PARENS_AROUND_GETTEXT_N compile-time option which was meant to catch an inadvertent mistake which is too obscure to maintain this facility. The backstory of how USE_PARENS_AROUND_GETTEXT_N came about is: When I added the N_() macro in 65784830366 (i18n: add no-op _() and N_() wrappers, 2011-02-22) it was defined as: #define N_(msgid) (msgid) This is non-standard C, as was noticed and fixed in 642f85faab2 (i18n: avoid parenthesized string as array initializer, 2011-04-07). I.e. this needed to be defined as: #define N_(msgid) msgid Then in e62cd35a3e8 (i18n: log: mark parseopt strings for translation, 2012-08-20) when "builtin_log_usage" was marked for translation the string concatenation for passing to usage() added in 1c370ea4e51 (Show usage string for 'git log -h', 'git show -h' and 'git diff -h', 2009-08-06) was faithfully preserved: - "git log [<options>] [<since>..<until>] [[--] <path>...]\n" - " or: git show [options] <object>...", + N_("git log [<options>] [<since>..<until>] [[--] <path>...]\n") + N_(" or: git show [options] <object>..."), This was then fixed to be the expected array of usage strings in e66dc0cc4b1 (log.c: fix translation markings, 2015-01-06) rather than a string with multiple "\n"-delimited usage strings, and finally in 290c8e7a3fe (gettext.h: add parentheses around N_ expansion if supported, 2015-01-11) USE_PARENS_AROUND_GETTEXT_N was added to ensure this mistake didn't happen again. I think that even if this was a N_()-specific issue this USE_PARENS_AROUND_GETTEXT_N facility wouldn't be worth it, the issue would be too rare to worry about. But I also think that 290c8e7a3fe which introduced USE_PARENS_AROUND_GETTEXT_N misattributed the problem. The issue wasn't with the N_() macro added in e62cd35a3e8, but that before the N_() macro existed in the codebase the initial migration to parse_options() in 1c370ea4e51 continued passsing in a "\n"-delimited string, when the new API it was migrating to supported and expected the passing of an array. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24Merge branch 'es/trace2-log-parent-process-name'Libravatar Junio C Hamano1-0/+4
trace2 logs learned to show parent process name to see in what context Git was invoked. * es/trace2-log-parent-process-name: tr2: log parent process name tr2: make process info collection platform-generic
2021-08-24Merge branch 'js/expand-runtime-prefix'Libravatar Junio C Hamano1-0/+5
Pathname expansion (like "~username/") learned a way to specify a location relative to Git installation (e.g. its $sharedir which is $(prefix)/share), with "%(prefix)". * js/expand-runtime-prefix: expand_user_path: allow in-flight topics to keep using the old name interpolate_path(): allow specifying paths relative to the runtime prefix Use a better name for the function interpolating paths expand_user_path(): clarify the role of the `real_home` parameter expand_user_path(): remove stale part of the comment tests: exercise the RUNTIME_PREFIX feature
2021-08-19Makefile: remove archives before manipulating them with 'ar'Libravatar SZEDER Gábor1-2/+2
The rules creating the $(LIB_FILE) and $(XDIFF_LIB) archives used to be: $(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^ until commit 7b76d6bf22 (Makefile: add and use the ".DELETE_ON_ERROR" flag, 2021-06-29) removed the '$(RM) $@' part, claiming that "we can rely on the "c" (create) being present in ARFLAGS", and (I presume) assuming that it means that the named archive is created from scratch. Unfortunately, that's not what the 'c' flag does, it merely "Suppress the diagnostic message that is written to standard error by default when the archive is created" [1]. Consequently, all object files that are already present in an existing archive and are not replaced will remain there. This leads to linker errors in back-to-back builds of different revisions without a 'make clean' between them if source files going into these archives are renamed in between: # The last commit renaming files that go into 'libgit.a': # bc62692757 (hash-lookup: rename from sha1-lookup, 2020-12-31) # sha1-lookup.c => hash-lookup.c | 14 +++++++------- # sha1-lookup.h => hash-lookup.h | 12 ++++++------ $ git checkout bc62692757^ HEAD is now at 7a7d992d0d sha1-lookup: rename `sha1_pos()` as `hash_pos()` $ make [...] $ git checkout 7b76d6bf22 HEAD is now at 7b76d6bf22 Makefile: add and use the ".DELETE_ON_ERROR" flag $ make [...] AR libgit.a LINK git /usr/bin/ld: libgit.a(hash-lookup.o): in function `bsearch_hash': /home/szeder/src/git/hash-lookup.c:105: multiple definition of `bsearch_hash'; libgit.a(sha1-lookup.o):/home/szeder/src/git/sha1-lookup.c:105: first defined here collect2: error: ld returned 1 exit status make: *** [Makefile:2213: git] Error 1 Restore the original make rules to first remove $(LIB_FILE) and $(XDIFF_LIB) and then create them from scratch to avoid these build errors. [1] Quoting POSIX at: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ar.html Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05Makefile: normalize clobbering & xargs for tags targetsLibravatar Ævar Arnfjörð Bjarmason1-8/+9
Since the "tags", "TAGS" and "cscope.out" targets rely on piping into xargs with an "echo <list> | xargs" pattern, we need to make sure we're in an append mode. Unlike my recent change to make use of ".DELETE_ON_ERROR" in 7b76d6bf221 (Makefile: add and use the ".DELETE_ON_ERROR" flag, 2021-06-29), we really do need the "rm $@+" at the beginning (note, not "rm $@"). This is because the xargs command may decide to invoke the program multiple times. We need to make sure we've got a union of its results at the end. For "ctags" and "etags" we used the "-a" flag for this, for cscope that behavior is the default. Its "-u" flag disables its equivalent of an implicit "-a" flag. Let's also consistently use the $@ and $@+ names instead of needlessly hardcoding or referring to more verbose names in the "tags" and "TAGS" rules. These targets could perhaps be improved in the future by factoring this "echo <list> | xargs" pattern so that we make intermediate tags files for each source file, and then assemble them into one "tags" file at the end. The etags manual page suggests that doing that (or perhaps just --update) might be counter-productive, in any case, the tag building is fast enough for me, so I'm leaving that for now. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05Makefile: remove "cscope.out", not "cscope*" in cscope.out targetLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Before we generate a "cscope.out" file, remove that file explicitly, and not everything matching "cscope*". This doesn't change any behavior of the Makefile in practice, but makes this rule less confusing, and consistent with other similar rules. The cscope target was added in a2a9150bf06 (makefile: Add a cscope target, 2007-10-06). It has always referred to cscope* instead of to cscope.out in .gitignore and the "clean" target, even though we only ever generated a cscope.out file. This was seemingly done to aid use-cases where someone invoked cscope with the "-q" flag, which would make it create a "cscope.in.out" and "cscope.po.out" files in addition to "cscope.out". But us removing those files we never generated is confusing, so let's only remove the file we need to, furthermore let's use the "-f" flag to explicitly name the cscope.out file, even though it's the default if not "-f" argument is supplied. It is somewhat inconsistent to change from the glob here but not in the "clean" rule and .gitignore, an earlier version of this change updated those as well, but see [1][2] for why they were kept. 1. https://lore.kernel.org/git/87k0lit57x.fsf@evledraar.gmail.com/ 2. https://lore.kernel.org/git/87im0kn983.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-04Merge branch 'ab/getcwd-test'Libravatar Junio C Hamano1-0/+1
Portability test update. * ab/getcwd-test: t0001: fix broken not-quite getcwd(3) test in bed67874e2
2021-07-30t0001: fix broken not-quite getcwd(3) test in bed67874e2Libravatar Ævar Arnfjörð Bjarmason1-0/+1
With a54e938e5b (strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD, 2017-03-26) we had t0001 break on systems like OpenBSD and AIX whose getcwd(3) has standard (but not like glibc et al) behavior. This was partially fixed in bed67874e2 (t0001: skip test with restrictive permissions if getpwd(3) respects them, 2017-08-07). The problem with that fix is that while its analysis of the problem is correct, it doesn't actually call getcwd(3), instead it invokes "pwd -P". There is no guarantee that "pwd -P" is going to call getcwd(3), as opposed to e.g. being a shell built-in. On AIX under both bash and ksh this test breaks because "pwd -P" will happily display the current working directory, but getcwd(3) called by the "git init" we're testing here will fail to get it. I checked whether clobbering the $PWD environment variable would affect it, and it didn't. Presumably these shells keep track of their working directory internally. There's possible follow-up work here in teaching strbuf_getcwd() to get the working directory with whatever method "pwd" uses on these platforms. See [1] for a discussion of that, but let's take the easy way out here and just skip these tests by fixing the GETCWD_IGNORES_PERMS prerequisite to match the limitations of strbuf_getcwd(). 1. https://lore.kernel.org/git/b650bef5-d739-d98d-e9f1-fa292b6ce982@web.de/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-28Merge branch 'ew/many-alternate-optim'Libravatar Junio C Hamano1-0/+3
Optimization for repositories with many alternate object store. * ew/many-alternate-optim: oidtree: a crit-bit tree for odb_loose_cache oidcpy_with_padding: constify `src' arg make object_directory.loose_objects_subdir_seen a bitmap avoid strlen via strbuf_addstr in link_alt_odb_entry speed up alt_odb_usable() with many alternates
2021-07-26tests: exercise the RUNTIME_PREFIX featureLibravatar Johannes Schindelin1-0/+5
Originally, we refrained from adding a regression test in 7b6c6496374 (system_path(): Add prefix computation at runtime if RUNTIME_PREFIX set, 2008-08-10), and in 226c0ddd0d6 (exec_cmd: RUNTIME_PREFIX on some POSIX systems, 2018-04-10). The reason was that it was deemed too tricky to test. Turns out that it is not tricky to test at all: we simply create a pseudo-root, copy the `git` executable into the `git/` subdirectory of that pseudo-root, then copy a script into the `libexec/git-core/` directory and expect that to be picked up. As long as the trash directory is in a location where binaries can be executed, this works. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22tr2: make process info collection platform-genericLibravatar Emily Shaffer1-0/+4
To pave the way for non-Windows platforms to define trace2_collect_process_info(), reorganize the stub-or-definition schema to something which doesn't directly reference Windows. Platforms which want to collect parent process information in the future should: 1. Add an implementation to compat/ (e.g. compat/somearch/procinfo.c) 2. Add that object to COMPAT_OBJS to config.mak.uname (e.g. COMPAT_OBJS += compat/somearch/procinfo.o) 3. Define HAVE_PLATFORM_PROCINFO in config.mak.uname In the Windows case, this definition lives in compat/win32/trace2_win32_process_info.c, which is already conditionally added to COMPAT_OBJS; so let's add HAVE_PLATFORM_PROCINFO to hint to the build that compat/stub/procinfo.c should not be used. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22Merge branch 'js/ci-windows-update'Libravatar Junio C Hamano1-1/+4
GitHub Actions / CI update. * js/ci-windows-update: ci: accelerate the checkout ci (vs-build): build with NO_GETTEXT artifacts-tar: respect NO_GETTEXT ci (windows): transfer also the Git-tracked files to the test jobs ci: upgrade to using actions/{up,down}load-artifacts v2 ci (vs-build): use `cmd` to copy the DLLs, not `powershell` ci: use the new GitHub Action to download git-sdk-64-minimal
2021-07-22Makefile: don't use "FORCE" for tags targetsLibravatar Ævar Arnfjörð Bjarmason1-8/+12
Remove the "FORCE" dependency from the "tags", "TAGS" and "cscope" targets, instead make them depend on whether or not the relevant source files have changed. For the cscope target we need to change it to depend on the actual generated file while we generate while we're at it, as the next commit will discuss we always generate a cscope.out file. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-16Merge branch 'jt/partial-clone-submodule-1'Libravatar Junio C Hamano1-0/+1
Prepare the internals for lazily fetching objects in submodules from their promisor remotes. * jt/partial-clone-submodule-1: promisor-remote: teach lazy-fetch in any repo run-command: refactor subprocess env preparation submodule: refrain from filtering GIT_CONFIG_COUNT promisor-remote: support per-repository config repository: move global r_f_p_c to repo struct
2021-07-16Merge branch 'ab/make-delete-on-error'Libravatar Junio C Hamano1-11/+18
Use ".DELETE_ON_ERROR" pseudo target to simplify our Makefile. * ab/make-delete-on-error: Makefile: add and use the ".DELETE_ON_ERROR" flag
2021-07-08Merge branch 'dd/svn-test-wo-locale-a'Libravatar Junio C Hamano1-0/+7
"git-svn" tests assumed that "locale -a", which is used to pick an available UTF-8 locale, is available everywhere. A knob has been introduced to allow testers to specify a suitable locale to use. * dd/svn-test-wo-locale-a: t: use user-specified utf-8 locale for testing svn
2021-07-07oidtree: a crit-bit tree for odb_loose_cacheLibravatar Eric Wong1-0/+3
This saves 8K per `struct object_directory', meaning it saves around 800MB in my case involving 100K alternates (half or more of those alternates are unlikely to hold loose objects). This is implemented in two parts: a generic, allocation-free `cbtree' and the `oidtree' wrapper on top of it. The latter provides allocation using alloc_state as a memory pool to improve locality and reduce free(3) overhead. Unlike oid-array, the crit-bit tree does not require sorting. Performance is bound by the key length, for oidtree that is fixed at sizeof(struct object_id). There's no need to have 256 oidtrees to mitigate the O(n log n) overhead like we did with oid-array. Being a prefix trie, it is natively suited for expanding short object IDs via prefix-limited iteration in `find_short_object_filename'. On my busy workstation, p4205 performance seems to be roughly unchanged (+/-8%). Startup with 100K total alternates with no loose objects seems around 10-20% faster on a hot cache. (800MB in memory savings means more memory for the kernel FS cache). The generic cbtree implementation does impose some extra overhead for oidtree in that it uses memcmp(3) on "struct object_id" so it wastes cycles comparing 12 extra bytes on SHA-1 repositories. I've not yet explored reducing this overhead, but I expect there are many places in our code base where we'd want to investigate this. More information on crit-bit trees: https://cr.yp.to/critbit.html Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-06artifacts-tar: respect NO_GETTEXTLibravatar Johannes Schindelin1-1/+4
We obviously do not want to bundle `.mo` files during `make artifacts-tar NO_GETTEXT=Yep`, but that was the case. To fix that, go a step beyond just fixing the symptom, and simply define the lists of `.po` and `.mo` files as empty if `NO_GETTEXT` is set. Helped-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-29Makefile: add QUIET_GEN to "cscope" targetLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Don't show the very verbose $(FIND_SOURCE_FILES) command on every "make cscope" invocation. See my recent 3c80fcb591 (Makefile: add QUIET_GEN to "tags" and "TAGS" targets, 2021-03-28) for the same fix for the other adjacent targets. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-29Makefile: move ".PHONY: cscope" near its targetLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Move the ".PHONY: cscope" rule to live alongside the "cscope" target itself, not to be all the way near the bottom where we define the "FORCE" rule. That line was last modified in 2f76919517e (MinGW: avoid collisions between "tags" and "TAGS", 2010-09-28). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-29Makefile: add and use the ".DELETE_ON_ERROR" flagLibravatar Ævar Arnfjörð Bjarmason1-11/+18
Use the GNU make ".DELETE_ON_ERROR" flag in our main Makefile, as we already do in the Documentation/Makefile since db10fc6c09f (doc: simplify Makefile using .DELETE_ON_ERROR, 2021-05-21). Now if a command to make X fails X will be removed, the default behavior of GNU make is to only do so if "make" itself is interrupted with a signal. E.g. if we now intentionally break one of the rules with: - mv $@+ $@ + mv $@+ $@ && \ + false We'll get output like: $ make git CC git.o LINK git make: *** [Makefile:2179: git] Error 1 make: *** Deleting file 'git' $ file git git: cannot open `git' (No such file or directory) Before this change we'd leave the file in place in under this scenario. As in db10fc6c09f this allows us to remove patterns of removing leftover $@ files at the start of rules, since previous failing runs of the Makefile won't have left those littered around anymore. I'm not as confident that we should be replacing the "mv $@+ $@" pattern entirely, since that means that external programs or one of our other Makefiles might race and get partial content. I'm not changing $(REMOTE_CURL_ALIASES) since that uses a ln/ln -s/cp dance, and would require the addition of "-f" flags if the "rm" at the start was removed. I've also got plans to fix that ln/ln -s/cp pattern in another series. For $(LIB_FILE) and $(XDIFF_LIB) we can rely on the "c" (create) being present in ARFLAGS. I'm not changing "$(ETAGS_TARGET)", "tags" and "cscope" because they've got a messy combination of removing "$@+" not "$@" at the beginning, or "$@*". I'm also addressing those in another series. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-28promisor-remote: teach lazy-fetch in any repoLibravatar Jonathan Tan1-0/+1
This is one step towards supporting partial clone submodules. Even after this patch, we will still lack partial clone submodules support, primarily because a lot of Git code that accesses submodule objects does so by adding their object stores as alternates, meaning that any lazy fetches that would occur in the submodule would be done based on the config of the superproject, not of the submodule. This also prevents testing of the functionality in this patch by user-facing commands. So for now, test this mechanism using a test helper. Besides that, there is some code that uses the wrapper functions like has_promisor_remote(). Those will need to be checked to see if they could support the non-wrapper functions instead (and thus support any repository, not just the_repository). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-08t: use user-specified utf-8 locale for testing svnLibravatar Đoàn Trần Công Danh1-0/+7
In some test-cases, UTF-8 locale is required. To find such locale, we're using the first available UTF-8 locale that returned by "locale -a". However, the locale(1) utility is unavailable on some systems, e.g. Linux with musl libc. However, without "locale -a", we can't guess provided UTF-8 locale. Add a Makefile knob GIT_TEST_UTF8_LOCALE and activate it for linux-musl in our CI system. Rename t/lib-git-svn.sh:prepare_a_utf8_locale to prepare_utf8_locale, since we no longer prepare the variable named "a_utf8_locale", but set up a fallback value for GIT_TEST_UTF8_LOCALE instead. The fallback will be LC_ALL, LANG environment variable, or the first UTF-8 locale from output of "locale -a", in that order. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-22Merge branch 'jh/simple-ipc-sans-pthread'Libravatar Junio C Hamano1-2/+20
The "simple-ipc" did not compile without pthreads support, but the build procedure was not properly account for it. * jh/simple-ipc-sans-pthread: simple-ipc: correct ifdefs when NO_PTHREADS is defined
2021-05-21simple-ipc: correct ifdefs when NO_PTHREADS is definedLibravatar Jeff Hostetler1-2/+20
Simple IPC always requires threads (in addition to various platform-specific IPC support). Fix the ifdefs in the Makefile to define SUPPORTS_SIMPLE_IPC when appropriate. Previously, the Unix version of the code would only verify that Unix domain sockets were available. This problem was reported here: https://lore.kernel.org/git/YKN5lXs4AoK%2FJFTO@coredump.intra.peff.net/T/#m08be8f1942ea8a2c36cfee0e51cdf06489fdeafc Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-20Merge branch 'ab/perl-makefile-cleanup'Libravatar Junio C Hamano1-4/+9
Build procedure clean-up. * ab/perl-makefile-cleanup: Makefile: make PERL_DEFINES recursively expanded perl: use mock i18n functions under NO_GETTEXT=Y Makefile: regenerate *.pm on NO_PERL_CPAN_FALLBACKS change Makefile: regenerate perl/build/* if GIT-PERL-DEFINES changes Makefile: don't re-define PERL_DEFINES
2021-05-14Merge branch 'ba/object-info'Libravatar Junio C Hamano1-0/+1
Over-the-wire protocol learns a new request type to ask for object sizes given a list of object names. * ba/object-info: object-info: support for retrieving object info
2021-05-13Makefile: make PERL_DEFINES recursively expandedLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Since 07d90eadb50 (Makefile: add Perl runtime prefix support, 2018-04-10) PERL_DEFINES has been a simply-expanded variable, let's make it recursively expanded instead. This change doesn't matter for the correctness of the logic. Whether we used simply-expanded or recursively expanded didn't change what we wrote out in GIT-PERL-DEFINES, but being consistent with other rules makes this easier to understand. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-06perl: use mock i18n functions under NO_GETTEXT=YLibravatar Ævar Arnfjörð Bjarmason1-0/+3
Change the logic of the i18n functions I added in 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18) to use pass-through functions when NO_GETTEXT is defined. This speeds up the compilation time of commands that use this library when NO_GETTEXT=Y is in effect. Loading it and POSIX.pm is around 20ms on my machine, whereas it takes 2ms to just instantiate perl itself. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-06Makefile: regenerate *.pm on NO_PERL_CPAN_FALLBACKS changeLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Regenerate the *.pm files in perl/build/* if the NO_PERL_CPAN_FALLBACKS flag added to the *.pm files in 1aca69c0195 (perl Git::LoadCPAN: emit better errors under NO_PERL_CPAN_FALLBACKS, 2018-03-03) is changed. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-06Makefile: regenerate perl/build/* if GIT-PERL-DEFINES changesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change the logic to generate perl/build/* to regenerate those files if GIT-PERL-DEFINES changes. This ensures that e.g. changing localedir will result in correctly re-generated files. I don't think that ever worked. The brokenness pre-dates my 20d2a30f8ff (Makefile: replace perl/Makefile.PL with simple make rules, 2017-12-10). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-06Makefile: don't re-define PERL_DEFINESLibravatar Ævar Arnfjörð Bjarmason1-3/+4
Since 07d90eadb50 (Makefile: add Perl runtime prefix support, 2018-04-10) we have been declaring PERL_DEFINES right after assigning to it, with the effect that the first PERL_DEFINES was ignored. That bug didn't matter in practice since the first line had all the same variables as the second, so we'd correctly re-generate everything. It just made for confusing reading. Let's remove that first assignment, and while we're at it split these across lines to make them more maintainable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>