summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2021-11-29Merge branch 'ab/sh-retire-helper-functions'Libravatar Junio C Hamano1-16/+10
Make a few helper functions unused and then lose them. * ab/sh-retire-helper-functions: git-sh-setup: remove "sane_grep", it's not needed anymore git-sh-setup: remove unused sane_egrep() function git-instaweb: unconditionally assume that gitweb is mod_perl capable Makefile: remove $(NO_CURL) from $(SCRIPT_DEFINES) Makefile: remove $(GIT_VERSION) from $(SCRIPT_DEFINES) Makefile: move git-SCRIPT-DEFINES adjacent to $(SCRIPT_DEFINES)
2021-10-29Merge branch 'ab/make-sparse-for-real'Libravatar Junio C Hamano1-1/+1
Fix-up for a recent topic. * ab/make-sparse-for-real: Makefile: remove redundant GIT-CFLAGS dependency from "sparse"
2021-10-21Makefile: remove redundant GIT-CFLAGS dependency from "sparse"Libravatar Ævar Arnfjörð Bjarmason1-1/+1
The "sparse" target needed the GIT-CFLAGS dependency before my c234e8a0ecf (Makefile: make the "sparse" target non-.PHONY, 2021-09-23), but since then it depends on the corresponding *.o files, which in turn depend on the correct header files, as well as on GIT-CFLAGS. There's no need to re-state this dependency here. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21git-sh-setup: remove "sane_grep", it's not needed anymoreLibravatar Ævar Arnfjörð Bjarmason1-5/+1
Remove the sane_grep() shell function in git-sh-setup. The two reasons for why it existed don't apply anymore: 1. It was added due to GNU grep supporting GREP_OPTIONS. See e1622bfcbad (Protect scripted Porcelains from GREP_OPTIONS insanity, 2009-11-23). Newer versions of GNU grep ignore that, but even on older versions its existence won't matter, none of these sane_grep() uses care about grep's output, they're merely using it to check if a string exists in a file or stream. We also don't care about the "LC_ALL=C" that "sane_grep" was using, these greps for fixed or ASCII strings will behave the same under any locale. 2. The SANE_TEXT_GREP added in 71b401032b9 (sane_grep: pass "-a" if grep accepts it, 2016-03-08) isn't needed either, none of these grep uses deal with binary data. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21Makefile: remove $(NO_CURL) from $(SCRIPT_DEFINES)Libravatar Ævar Arnfjörð Bjarmason1-2/+1
Stop including $(NO_CURL) in $(SCRIPT_DEFINES). The "@NO_CURL@" replacement added in 6c5c62f3401 (Print an error if cloning a http repo and NO_CURL is set, 2006-02-15) has not been referenced by anything in-tree since 49eb8d39c78 (Remove contrib/examples/*, 2018-03-25). That commit removed the reference from contrib/examples/*, but this @@NO_CURL@@ hasn't been used since git-pull.sh was the primary entry point for "git pull". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21Makefile: remove $(GIT_VERSION) from $(SCRIPT_DEFINES)Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Remove the $(GIT_VERSION) from $(SCRIPT_DEFINES). Now every time HEAD changes in a development copy we don't need to re-build the scripts and script libraries. This has not been needed since 2b9391bc675 (Makefile: do not replace @@GIT_VERSION@@ in shell scripts, 2012-06-20). On my setup this changes the re-making of 44 targets in a development copy where moved HEAD to 27. The $(GIT_VERSION) was seemingly left here by mistake or omission. We didn't need it since 2b9391bc675, but in the later e4dd89ab984 (Makefile: update scripts when build-time parameters change, 2012-06-20) it was added to SCRIPT_DEFINES. The two were part of the same series of patches, and given the summary in [1] and [2] it looks like this was probably a case of some earlier version of a later patch being combined with an updated earlier patch. 1. https://lore.kernel.org/git/20120619232231.GA6328@sigill.intra.peff.net/ 2. https://lore.kernel.org/git/20120619232453.GB6496@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21Makefile: move git-SCRIPT-DEFINES adjacent to $(SCRIPT_DEFINES)Libravatar Ævar Arnfjörð Bjarmason1-8/+7
When "GIT-SCRIPT-DEFINES" was added in e4dd89ab984 (Makefile: update scripts when build-time parameters change, 2012-06-20) the rules for generating the scripts themselves were moved further away from the "cmd_munge_script" added in 46bac904581 (Do not install shell libraries executable, 2010-01-31). Let's move these around so that the variables and defines needed by given targets immediately precede them. This is not needed for any subsequent changes to work, but makes the code consistent with how GIT-PERL-DEFINES is structured. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18Merge branch 'js/retire-preserve-merges'Libravatar Junio C Hamano1-2/+0
The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch.<name>.rebase values t5520: do not use `pull.rebase=preserve`
2021-10-13Merge branch 'ab/make-sparse-for-real'Libravatar Junio C Hamano1-3/+6
Prevent "make sparse" from running for the source files that haven't been modified. * ab/make-sparse-for-real: Makefile: make the "sparse" target non-.PHONY
2021-10-13Merge branch 'ab/config-based-hooks-1'Libravatar Junio C Hamano1-13/+15
Mostly preliminary clean-up in the hook API. * ab/config-based-hooks-1: hook-list.h: add a generated list of hooks, like config-list.h hook.c users: use "hook_exists()" instead of "find_hook()" hook.c: add a hook_exists() wrapper and use it in bugreport.c hook.[ch]: move find_hook() from run-command.c to hook.c Makefile: remove an out-of-date comment Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H) Makefile: stop hardcoding {command,config}-list.h Makefile: mark "check" target as .PHONY
2021-10-11Merge branch 'ab/sanitize-leak-ci'Libravatar Junio C Hamano1-0/+5
CI learns to run the leak sanitizer builds. * 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-27hook-list.h: add a generated list of hooks, like config-list.hLibravatar Ævar Arnfjörð Bjarmason1-1/+7
Make githooks(5) the source of truth for what hooks git supports, and punt out early on hooks we don't know about in find_hook(). This ensures that the documentation and the C code's idea about existing hooks doesn't diverge. We still have Perl and Python code running its own hooks, but that'll be addressed by Emily Shaffer's upcoming "git hook run" command. This resolves a long-standing TODO item in bugreport.c of there being no centralized listing of hooks, and fixes a bug with the bugreport listing only knowing about 1/4 of the p4 hooks. It didn't know about the recent "reference-transaction" hook either. We could make the find_hook() function die() or BUG() out if the new known_hook() returned 0, but let's make it return NULL just as it does when it can't find a hook of a known type. Making it die() is overly anal, and unlikely to be what we need in catching stupid typos in the name of some new hook hardcoded in git.git's sources. By making this be tolerant of unknown hook names, changes in a later series to make "git hook run" run arbitrary user-configured hook names will be easier to implement. I have not been able to directly test the CMake change being made here. Since 4c2c38e800 (ci: modification of main.yml to use cmake for vs-build job, 2020-06-26) some of the Windows CI has a hard dependency on CMake, this change works there, and is to my eyes an obviously correct use of a pattern established in previous CMake changes, namely: - 061c2240b1 (Introduce CMake support for configuring Git, 2020-06-12) - 709df95b78 (help: move list_config_help to builtin/help, 2020-04-16) - 976aaedca0 (msvc: add a Makefile target to pre-generate the Visual Studio solution, 2019-07-29) The LC_ALL=C is needed because at least in my locale the dash ("-") is ignored for the purposes of sorting, which results in a different order. I'm not aware of anything in git that has a hard dependency on the order, but e.g. the bugreport output would end up using whatever locale was in effect when git was compiled. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27hook.[ch]: move find_hook() from run-command.c to hook.cLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Move the find_hook() function from run-command.c to a new hook.c library. This change establishes a stub library that's pretty pointless right now, but will see much wider use with Emily Shaffer's upcoming "configuration-based hooks" series. Eventually all the hook related code will live in hook.[ch]. Let's start that process by moving the simple find_hook() function over as-is. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Makefile: remove an out-of-date commentLibravatar Ævar Arnfjörð Bjarmason1-7/+0
This comment added in dfea575017 (Makefile: lazily compute header dependencies, 2010-01-26) has been out of date since 92b88eba9f (Makefile: use `git ls-files` to list header files, if possible, 2019-03-04), when we did exactly what it tells us not to do and added $(GENERATED_H) to $(OBJECTS) dependencies. The rest of it was also somewhere between inaccurate and outdated, since as of b8ba629264 (Makefile: fold MISC_H into LIB_H, 2012-06-20) it's not followed by a list of header files, that got moved earlier in the file into LIB_H in 60d24dd255 (Makefile: fold XDIFF_H and VCSSVN_H into LIB_H, 2012-07-06). Let's just remove it entirely, to the extent that we have anything useful to say here the comment on the "USE_COMPUTED_HEADER_DEPENDENCIES" variable a few lines above this change does the job for us. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H)Libravatar Ævar Arnfjörð Bjarmason1-3/+2
Change the "cmd.sh > $@+ && mv $@+ $@" pattern used for generating the config-list.h and command-list.h to just "cmd.sh >$@". This was needed as a guard to ensure that we don't have an empty file if the script failed, but since 7b76d6bf221 (Makefile: add and use the ".DELETE_ON_ERROR" flag, 2021-06-29) GNU make ensures that doesn't happen. There's still a lot of other places in the Makefile where we needlessly use this pattern, but I'm just changing these because I'm about to add a new $(GENERATED_H) target, let's have them all look and act the same way. Even with ".DELETE_ON_ERROR" there is still a point to using the "mv $@+ $@" pattern in some cases, e.g. to ensure that you have a working binary during recompilation (see [1] for the start of a long discussion about that), but that doesn't apply here. Nothing external uses $(GENERATED_H) directly, it's only ever used in the context of the Makefile's own dependency (re-)generation. 1. https://lore.kernel.org/git/8735t93h0u.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Makefile: stop hardcoding {command,config}-list.hLibravatar Ævar Arnfjörð Bjarmason1-2/+4
Change various places that hardcode the names of these two files to refer to either $(GENERATED_H), or to a new generated-hdrs target. That target is consistent with the *-objs targets I recently added in 029bac01a8 (Makefile: add {program,xdiff,test,git,fuzz}-objs & objects targets, 2021-02-23). A subsequent commit will add a new generated hook-list.h. By doing this refactoring we'll only need to add the new file to the GENERATED_H variable, not EXCEPT_HDRS, the vcbuild/README etc. Hardcoding command-list.h there seems to have been a case of copy/paste programming in 976aaedca0 (msvc: add a Makefile target to pre-generate the Visual Studio solution, 2019-07-29). The config-list.h was added later in 709df95b78 (help: move list_config_help to builtin/help, 2020-04-16). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Makefile: mark "check" target as .PHONYLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Fix a bug in 44c9e8594e (Fix up header file dependencies and add sparse checking rules, 2005-07-03), we never marked the phony "check" target as such. Perhaps we should just remove it, since as of a combination of 912f9980d2 (Makefile: help people who run 'make check' by mistake, 2008-11-11) 0bcd9ae85d (sparse: Fix errors due to missing target-specific variables, 2011-04-21) we've been suggesting the user run "make sparse" directly. But under that mode it still does something, as well as directing the user to run "make test" under non-sparse. So let's punt that and narrowly fix the PHONY bug. 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: make the "sparse" target non-.PHONYLibravatar Ævar Arnfjörð Bjarmason1-3/+6
Change the "sparse" target and its *.sp dependencies to be non-.PHONY. Before this change "make sparse" would take ~5s to re-run all the *.c files through "cgcc", after it it'll create an empty *.sp file sitting alongside the *.c file, only if the *.c file or its dependencies are newer than the *.sp is the *.sp re-made. We ensure that the recursive dependencies are correct by depending on the *.o file, which in turn will have correct dependencies by either depending on all header files, or under "COMPUTE_HEADER_DEPENDENCIES=yes" the headers it needs. This means that a plain "make sparse" is much slower, as we'll now need to make the *.o files just to create the *.sp files, but incrementally creating the *.sp files is *much* faster and less verbose, it thus becomes viable to run "sparse" along with "all" as e.g. "git rebase --exec 'make all sparse'". On my box with -j8 "make sparse" was fast before, or around 5 seconds, now it only takes that long the first time, and the common case is <100ms, or however long it takes GNU make to stat the *.sp file and see that all the corresponding *.c file and its dependencies are older. See 0bcd9ae85d7 (sparse: Fix errors due to missing target-specific variables, 2011-04-21) for the modern implementation of the sparse target being changed here. It is critical that we use -Wsparse-error here, otherwise the error would only show up once, but we'd successfully create the empty *.sp file, and running a second time wouldn't show the error. I'm therefore not putting it into SPARSE_FLAGS or SP_EXTRA_FLAGS, it's not optional, the Makefile logic won't behave properly without it. Appending to $@ without a move is OK here because we're using the .DELETE_ON_ERROR Makefile feature. See 7b76d6bf221 (Makefile: add and use the ".DELETE_ON_ERROR" flag, 2021-06-29). GNU make ensures that on error this file will be removed. 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-07rebase: drop support for `--preserve-merges`Libravatar Johannes Schindelin1-2/+0
This option was deprecated in favor of `--rebase-merges` some time ago, and now we retire it. To assist users to transition away, we do not _actually_ remove the option, but now we no longer implement the functionality. Instead, we offer a helpful error message suggesting which option to use. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-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