summaryrefslogtreecommitdiff
path: root/contrib/buildsystems
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'jh/simple-ipc-sans-pthread'Junio C Hamano2021-05-221-1/+9
|\ | | | | | | | | | | | | | | 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
| * simple-ipc: correct ifdefs when NO_PTHREADS is definedJeff Hostetler2021-05-211-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'js/cmake-vsbuild'Junio C Hamano2021-04-071-7/+19
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake update for vsbuild. * js/cmake-vsbuild: cmake(install): include vcpkg dlls cmake: add a preparatory work-around to accommodate `vcpkg` cmake(install): fix double .exe suffixes cmake: support SKIP_DASHED_BUILT_INS
| * | cmake(install): include vcpkg dllsDennis Ameling2021-03-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our CMake configuration generates not only build definitions, but also install definitions: After building Git using `msbuild git.sln`, the built artifacts can be installed via `msbuild INSTALL.vcxproj`. To specify _where_ the files should be installed, the `-DCMAKE_INSTALL_PREFIX=<path>` option can be used when running CMake. However, this process would really only install the files that were just built. On Windows, we need more than that: We also need the `.dll` files of the dependencies (such as libcurl). The `vcpkg` ecosystem, which we use to obtain those dependencies, can be asked to install said `.dll` files really easily, so let's do that. This requires more than just the built `vcpkg` artifacts in the CI build definition; We now clone the `vcpkg` repository so that the relevant CMake scripts are available, in particular the ones related to defining the toolchain. Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | cmake: add a preparatory work-around to accommodate `vcpkg`Johannes Schindelin2021-03-291-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are about to add support for installing the `.dll` files of Git's dependencies (such as libcurl) in the CMake configuration. The `vcpkg` ecosystem from which we get said dependencies makes that relatively easy: simply turn on `X_VCPKG_APPLOCAL_DEPS_INSTALL`. However, current `vcpkg` introduces a limitation if one does that: While it is totally cool with CMake to specify multiple targets within one invocation of `install(TARGETS ...) (at least according to https://cmake.org/cmake/help/latest/command/install.html#command:install), `vcpkg`'s parser insists on a single target per `install(TARGETS ...)` invocation. Well, that's easily accomplished: Let's feed the targets individually to the `install(TARGETS ...)` function in a `foreach()` look. This also has the advantage that we do not have to manually cull off the two entries from the `${PROGRAMS_BUILT}` array before scheduling the remainder to be installed into `libexec/git-core`. Instead, we iterate through the array and decide for each entry where it wants to go. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | cmake(install): fix double .exe suffixesDennis Ameling2021-03-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By mistake, the `.exe` extension is appended _twice_ when installing the dashed executables into `libexec/git-core/` on Windows (the extension is already appended when adding items to the `git_links` list in the `#Creating hardlinks` section). Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | cmake: support SKIP_DASHED_BUILT_INSJohannes Schindelin2021-03-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just like the Makefile-based build learned to skip hard-linking the dashed built-ins in 179227d6e21 (Optionally skip linking/copying the built-ins, 2020-09-21), this patch teaches the CMake-based build the same trick. Note: In contrast to the Makefile-based process, the built-ins would only be linked during installation, not already when Git is built. Therefore, the CMake-based build that we use in our CI builds _already_ does not link those built-ins (because the files are not installed anywhere, they are used to run the test suite in-place). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jh/simple-ipc'Junio C Hamano2021-04-021-1/+7
|\ \ \ | |/ / |/| / | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A simple IPC interface gets introduced to build services like fsmonitor on top. * jh/simple-ipc: t0052: add simple-ipc tests and t/helper/test-simple-ipc tool simple-ipc: add Unix domain socket implementation unix-stream-server: create unix domain socket under lock unix-socket: disallow chdir() when creating unix domain sockets unix-socket: add backlog size option to unix_stream_listen() unix-socket: eliminate static unix_stream_socket() helper function simple-ipc: add win32 implementation simple-ipc: design documentation for new IPC mechanism pkt-line: add options argument to read_packetized_to_strbuf() pkt-line: add PACKET_READ_GENTLE_ON_READ_ERROR option pkt-line: do not issue flush packets in write_packetized_*() pkt-line: eliminate the need for static buffer in packet_write_gently()
| * simple-ipc: add Unix domain socket implementationJeff Hostetler2021-03-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create Unix domain socket based implementation of "simple-ipc". A set of `ipc_client` routines implement a client library to connect to an `ipc_server` over a Unix domain socket, send a simple request, and receive a single response. Clients use blocking IO on the socket. A set of `ipc_server` routines implement a thread pool to listen for and concurrently service client connections. The server creates a new Unix domain socket at a known location. If a socket already exists with that name, the server tries to determine if another server is already listening on the socket or if the socket is dead. If socket is busy, the server exits with an error rather than stealing the socket. If the socket is dead, the server creates a new one and starts up. If while running, the server detects that its socket has been stolen by another server, it automatically exits. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * unix-stream-server: create unix domain socket under lockJeff Hostetler2021-03-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a wrapper class for `unix_stream_listen()` that uses a ".lock" lockfile to create the unix domain socket in a race-free manner. Unix domain sockets have a fundamental problem on Unix systems because they persist in the filesystem until they are deleted. This is independent of whether a server is actually listening for connections. Well-behaved servers are expected to delete the socket when they shutdown. A new server cannot easily tell if a found socket is attached to an active server or is leftover cruft from a dead server. The traditional solution used by `unix_stream_listen()` is to force delete the socket pathname and then create a new socket. This solves the latter (cruft) problem, but in the case of the former, it orphans the existing server (by stealing the pathname associated with the socket it is listening on). We cannot directly use a .lock lockfile to create the socket because the socket is created by `bind(2)` rather than the `open(2)` mechanism used by `tempfile.c`. As an alternative, we hold a plain lockfile ("<path>.lock") as a mutual exclusion device. Under the lock, we test if an existing socket ("<path>") is has an active server. If not, we create a new socket and begin listening. Then we use "rollback" to delete the lockfile in all cases. This wrapper code conceptually exists at a higher-level than the core unix_stream_connect() and unix_stream_listen() routines that it consumes. It is isolated in a wrapper class for clarity. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * simple-ipc: add win32 implementationJeff Hostetler2021-03-151-0/+4
| | | | | | | | | | | | | | Create Windows implementation of "simple-ipc" using named pipes. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Remove support for v1 of the PCRE libraryÆvar Arnfjörð Bjarmason2021-01-231-4/+0
|/ | | | | | | | | | | | | | | | | | | | | | | Remove support for using version 1 of the PCRE library. Its use has been discouraged by upstream for a long time, and it's in a bugfix-only state. Anyone who was relying on v1 in particular got a nudge to move to v2 in e6c531b808 (Makefile: make USE_LIBPCRE=YesPlease mean v2, not v1, 2018-03-11), which was first released as part of v2.18.0. With this the LIBPCRE2 test prerequisites is redundant to PCRE. But I'm keeping it for self-documentation purposes, and to avoid conflict with other in-flight PCRE patches. I'm also not changing all of our own "pcre2" names to "pcre", i.e. the inverse of 6d4b5747f0 (grep: change internal *pcre* variable & function names to be *pcre1*, 2017-05-25). I don't see the point, and it makes the history/blame harder to read. Maybe if there's ever a PCRE v3... Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/cmake-extra-built-ins-fix'Junio C Hamano2020-12-141-4/+11
|\ | | | | | | | | | | | | VSbuild fix. * js/cmake-extra-built-ins-fix: cmake: determine list of extra built-ins dynamically
| * cmake: determine list of extra built-ins dynamicallyJohannes Schindelin2020-12-041-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | In 0a21d0e08902 (Makefile: mark git-maintenance as a builtin, 2020-12-01), we marked git-maintenance as a builtin in the Makefile, but forgot to do the same in `CMakeLists.txt`. Rather than always play catch-up and adjust `git_builtin_extra` manually, use the `BUILT_INS` definitions in the Makefile as authoritative source and generate `git_builtin_extra` dynamically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | ci(vs-build): stop passing the iconv library location explicitlyDennis Ameling2020-12-041-1/+1
|/ | | | | | | | | | | | | | | Something changed in `vcpkg` (which we use in our Visual C++ build to provide the dependencies such as libcurl) and our `vs-build` job started failing in CI. The reason is that we had a work-around in place to help CMake find iconv, and this work-around is neither needed nor does it work anymore. For the full discussion with the vcpkg project, see this comment: https://github.com/microsoft/vcpkg/issues/14780#issuecomment-735368280 Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake (Windows): recommend using Visual Studio's built-in CMake supportJohannes Schindelin2020-09-301-9/+17
| | | | | | | | | | | | | It is a lot more convenient to use than having to specify the configuration in CMake manually (does not matter whether using the command-line or CMake's GUI). While at it, recommend using `contrib/buildsystems/out/` as build directory also in the part that talks about running CMake manually. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake (Windows): initialize vcpkg/build dependencies automaticallyJohannes Schindelin2020-09-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The idea of having CMake support in Git's source tree is to enable contributors on Windows to start contributing with little effort. To that end, we just added some sensible defaults that will let users open the worktree in Visual Studio and start building. This expects the dependencies (such as zlib) to be available already, though. If they are not available, we expect the user to run `compat/vcbuild/vcpkg_install.bat`. Rather than requiring this step to be manual, detect the situation and run it as part of the CMake configuration step. Note that this obviously only applies to the scenario when we want to compile in Visual Studio (i.e. with MS Visual C), not with GCC. Therefore, we guard this new code block behind the `MSVC` conditional. This concludes our journey to make it as effortless as possible to start developing Git in Visual Studio: all the developer needs to do is to clone Git's repository, open the worktree via `File>Open>Folder...` and wait for CMake to finish configuring. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake (Windows): complain when encountering an unknown compilerJohannes Schindelin2020-09-301-0/+2
| | | | | | | | | | | We have some custom handling regarding the link options, which are specific to each compiler. Therefore: let's not just continue without setting the link options if configuring for a currently unhandled compiler, but error out. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake (Windows): let the `.dll` files be found when running the testsJohannes Schindelin2020-09-301-0/+3
| | | | | | | | | | | Contrary to Unix-ish platforms, the dependencies' shared libraries are not usually found in one central place. In our case, since we use `vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree. Let's make sure that they are in the search path when running the tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: quote the path accurately when editing `test-lib.sh`Johannes Schindelin2020-09-301-1/+1
| | | | | | | | | | By default, the build directory will be called something like `contrib/buildsystems/out/build/x64-Debug (default)` (note the space and the parentheses). We need to make sure that such a path is quoted properly when editing the assignment of the `GIT_BUILD_DIR` variable. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: fall back to using `vcpkg`'s `msgfmt.exe` on WindowsJohannes Schindelin2020-09-301-1/+5
| | | | | | | | We are already relying on `vcpkg` to manage our dependencies, including `libiconv`. Let's also use the `msgfmt.exe` from there. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: ensure that the `vcpkg` packages are found on WindowsJohannes Schindelin2020-09-281-0/+7
| | | | | | | | | | | | | | On Windows, we use the `vcpkg` project to manage the dependencies, via `compat/vcbuild/`. Let's make sure that these dependencies are found by default. This is needed because we are about to recommend loading the Git worktree as a folder into Visual Studio, relying on the automatic CMake support (which would make it relatively cumbersome to adjust the search path used by CMake manually). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: do find Git for Windows' shell interpreterJohannes Schindelin2020-09-281-1/+1
| | | | | | | | | | | | | | By default, Git for Windows does not install its `sh.exe` into the `PATH`. However, our current `CMakeLists.txt` expects to find a shell interpreter in the `PATH`. So let's fall back to looking in the default location where Git for Windows _does_ install a relatively convenient `sh.exe`: `C:\Program Files\Git\bin\sh.exe` Helped-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'os/vcbuild'Junio C Hamano2020-09-092-1/+2
|\ | | | | | | | | | | | | | | | | Fix build procedure for MSVC. * os/vcbuild: contrib/buildsystems: fix expat library name for generated vcxproj vcbuild: fix batch file name in README vcbuild: fix library name for expat with make MSVC=1
| * contrib/buildsystems: fix expat library name for generated vcxprojOrgad Shaneh2020-09-082-1/+2
| | | | | | | | | | | | | | | | expat.lib -> libexpat.lib (libexpatd.lib for debug build). Signed-off-by: Orgad Shaneh <orgads@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | drop vcs-svn experimentJeff King2020-08-131-21/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code in vcs-svn was started in 2010 as an attempt to build a remote-helper for interacting with svn repositories (as opposed to git-svn). However, we never got as far as shipping a mature remote helper, and the last substantive commit was e99d012a6bc in 2012. We do have a git-remote-testsvn, and it is even installed as part of "make install". But given the name, it seems unlikely to be used by anybody (you'd have to explicitly "git clone testsvn::$url", and there have been zero mentions of that on the mailing list since 2013, and even that includes the phrase "you might need to hack a bit to get it working properly"[1]). We also ship contrib/svn-fe, which builds on the vcs-svn work. However, it does not seem to build out of the box for me, as the link step misses some required libraries for using libgit.a. Curiously, the original build breakage bisects for me to eff80a9fd9 (Allow custom "comment char", 2013-01-16), which seems unrelated. There was an attempt to fix it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my system that only switches the error message. So it seems like the result is not really usable by anybody in practice. It would be wonderful if somebody wanted to pick up the topic again, and potentially it's worth carrying around for that reason. But the flip side is that people doing tree-wide operations have to deal with this code. And you can see the list with (replace "HEAD" with this commit as appropriate): { echo "--" git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD } | git log --no-merges --oneline e99d012a6bc.. --stdin which shows 58 times somebody had to deal with the code, generally due to a compile or test failure, or a tree-wide style fix or API change. Let's drop it and let anybody who wants to pick it up do so by resurrecting it from the git history. As a bonus, this also reduces the size of a stripped installation of Git from 21MB to 19MB. [1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/ Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | make git-fast-import a builtinJeff King2020-08-131-4/+1
| | | | | | | | | | | | | | | | | | | | There's no reason that git-fast-import benefits from being a separate binary. And as it links against libgit.a, it has a non-trivial disk footprint. Let's make it a builtin, which reduces the size of a stripped installation from 22MB to 21MB. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | make git-bugreport a builtinJeff King2020-08-131-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | There's no reason that bugreport has to be a separate binary. And since it links against libgit.a, it has a rather large disk footprint. Let's make it a builtin, which reduces the size of a stripped installation from 24MB to 22MB. This also simplifies our Makefile a bit. And we can take advantage of builtin niceties like RUN_SETUP_GENTLY. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | make credential helpers builtinsJeff King2020-08-131-19/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no real reason for credential helpers to be separate binaries. I did them this way originally under the notion that helper don't _need_ to be part of Git, and so can be built totally separately (and indeed, the ones in contrib/credential are). But the ones in our main Makefile build on libgit.a, and the resulting binaries are reasonably large. We can slim down our total disk footprint by just making them builtins. This reduces the size of: make strip install from 29MB to 24MB on my Debian system. Note that credential-cache can't operate without support for Unix sockets. Currently we just don't build it at all when NO_UNIX_SOCKETS is set. We could continue that with conditionals in the Makefile and our list of builtins. But instead, let's build a dummy implementation that dies with an informative message. That has two advantages: - it's simpler, because the conditional bits are all kept inside the credential-cache source - a user who is expecting it to exist will be told _why_ they can't use it, rather than getting the "credential-cache is not a git command" error which makes it look like the Git install is broken. Note that our dummy implementation does still respond to "-h" in order to appease t0012 (and this may be a little friendlier for users, as well). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: support for building git on windows with msvc and clang.Sibi Siddharthan2020-06-261-10/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for Visual Studio and Clang builds The minimum required version of CMake is upgraded to 3.15 because this version offers proper support for Clang builds on Windows. Libintl is not searched for when building with Visual Studio or Clang because there is no binary compatible version available yet. NOTE: In the link options invalidcontinue.obj has to be included. The reason for this is because by default, Windows calls abort()'s instead of setting errno=EINVAL when invalid arguments are passed to standard functions. This commit explains it in detail: 4b623d80f73528a632576990ca51e34c333d5dd6 On Windows the default generator is Visual Studio,so for Visual Studio builds do this: cmake `relative-path-to-srcdir` NOTE: Visual Studio generator is a multi config generator, which means that Debug and Release builds can be done on the same build directory. For Clang builds do this: On bash CC=clang cmake `relative-path-to-srcdir` -G Ninja -DCMAKE_BUILD_TYPE=[Debug or Release] On cmd set CC=Clang cmake `relative-path-to-srcdir` -G Ninja -DCMAKE_BUILD_TYPE=[Debug or Release] Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: support for building git on windows with mingwSibi Siddharthan2020-06-261-23/+94
| | | | | | | | | | | | | | | | | | | | This patch facilitates building git on Windows with CMake using MinGW NOTE: The funtions unsetenv and hstrerror are not checked in Windows builds. Reasons NO_UNSETENV is not compatible with Windows builds. lines 262-264 compat/mingw.h compat/mingw.h(line 25) provides a definition of hstrerror which conflicts with the definition provided in git-compat-util.h(lines 733-736). To use CMake on Windows with MinGW do this: cmake `relative-path-to-srcdir` -G "MinGW Makefiles" Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: support for testing git when building out of the source treeSibi Siddharthan2020-06-261-0/+20
| | | | | | | | | | | | | | | | | | | | | | This patch allows git to be tested when performin out of source builds. This involves changing GIT_BUILD_DIR in t/test-lib.sh to point to the build directory. Also some miscellaneous copies from the source directory to the build directory. The copies are: t/chainlint.sed needed by a bunch of test scripts po/is.po needed by t0204-gettext-rencode-sanity mergetools/tkdiff needed by t7800-difftool contrib/completion/git-prompt.sh needed by t9903-bash-prompt contrib/completion/git-completion.bash needed by t9902-completion contrib/svn-fe/svnrdump_sim.py needed by t9020-remote-svn NOTE: t/test-lib.sh is only modified when tests are run not during the build or configure. The trash directory is still srcdir/t Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: support for testing git with ctestSibi Siddharthan2020-06-261-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides an alternate way to test git using ctest. CTest ships with CMake, so there is no additional dependency being introduced. To perform the tests with ctest do this after building: ctest -j[number of jobs] NOTE: -j is optional, the default number of jobs is 1 Each of the jobs does this: cd t/ && sh t[something].sh The reason for using CTest is that it logs the output of the tests in a neat way, which can be helpful during diagnosis of failures. After the tests have run ctest generates three log files located in `build-directory`/Testing/Temporary/ These log files are: CTestCostData.txt: This file contains the time taken to complete each test. LastTestsFailed.log: This log file contains the names of the tests that have failed in the run. LastTest.log: This log file contains the log of all the tests that have run. A snippet of the file is given below. 10/901 Testing: D:/my/git-master/t/t0009-prio-queue.sh 10/901 Test: D:/my/git-master/t/t0009-prio-queue.sh Command: "sh.exe" "D:/my/git-master/t/t0009-prio-queue.sh" Directory: D:/my/git-master/t "D:/my/git-master/t/t0009-prio-queue.sh" Output: ---------------------------------------------------------- ok 1 - basic ordering ok 2 - mixed put and get ok 3 - notice empty queue ok 4 - stack order passed all 4 test(s) 1..4 <end of output> Test time = 1.11 sec NOTE: Testing only works when building in source for now. Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: installation support for gitSibi Siddharthan2020-06-261-0/+49
| | | | | | | | | | | | | | | Install the built binaries and scripts using CMake This is very similar to `make install`. By default the destination directory(DESTDIR) is /usr/local/ on Linux To set a custom installation path do this: cmake `relative-path-to-srcdir` -DCMAKE_INSTALL_PREFIX=`preferred-install-path` Then run `make install` Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cmake: generate the shell/perl/python scripts and templates, translationsSibi Siddharthan2020-06-261-1/+110
| | | | | | | | | | | | | | | | Implement the placeholder substitution to generate scripted Porcelain commands, e.g. git-request-pull out of git-request-pull.sh Generate shell/perl/python scripts and template using CMake instead of using sed like the build procedure in the Makefile does. The text translations are only build if `msgfmt` is found in your path. NOTE: The scripts and templates are generated during configuration. Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Introduce CMake support for configuring GitSibi Siddharthan2020-06-121-0/+592
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment, the recommended way to configure Git's builds is to simply run `make`. If that does not work, the recommended strategy is to look at the top of the `Makefile` to see whether any "Makefile knob" has to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`. Alternatively, Git also has an `autoconf` setup which allows configuring builds via `./configure [<option>...]`. Both of these options are fine if the developer works on Unix or Linux. But on Windows, we have to jump through hoops to configure a build (read: we force the user to install a full Git for Windows SDK, which occupies around two gigabytes (!) on disk and downloads about three quarters of a gigabyte worth of Git objects). The build infrastructure for Git is written around being able to run make, which is not supported natively on Windows. To help Windows developers a CMake build script is introduced here. With a working support CMake, developers on Windows need only install CMake, configure their build, load the generated Visual Studio solution and immediately start modifying the code and build their own version of Git. Likewise, developers on other platforms can use the convenient GUI tools provided by CMake to configure their build. So let's start building CMake support for Git. This is only the first step, and to make it easier to review, it only allows for configuring builds on the platform that is easiest to configure for: Linux. The CMake script checks whether the headers are present(eg. libgen.h), whether the functions are present(eg. memmem), whether the funtions work properly (eg. snprintf) and generate the required compile definitions for the platform. The script also searches for the required libraries, if it fails to find the required libraries the respective executables won't be built.(eg. If libcurl is not found then git-remote-http won't be built). This will help building Git easier. With a CMake script an out of source build of git is possible resulting in a clean source tree. Note: this patch asks for the minimum version v3.14 of CMake (which is not all that old as of time of writing) because that is the first version to offer a platform-independent way to generate hardlinks as part of the build. This is needed to generate all those hardlinks for the built-in commands of Git. Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.xJohannes Schindelin2020-01-161-2/+2
| | | | | | | | With the upgrade, the library names changed from libeay32/ssleay32 to libcrypto/libssl. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/azure-pipelines-msvc'Junio C Hamano2019-10-151-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CI updates. * js/azure-pipelines-msvc: ci: also build and test with MS Visual Studio on Azure Pipelines ci: really use shallow clones on Azure Pipelines tests: let --immediate and --write-junit-xml play well together test-tool run-command: learn to run (parts of) the testsuite vcxproj: include more generated files vcxproj: only copy `git-remote-http.exe` once it was built msvc: work around a bug in GetEnvironmentVariable() msvc: handle DEVELOPER=1 msvc: ignore some libraries when linking compat/win32/path-utils.h: add #include guards winansi: use FLEX_ARRAY to avoid compiler warning msvc: avoid using minus operator on unsigned types push: do not pretend to return `int` from `die_push_simple()`
| * vcxproj: only copy `git-remote-http.exe` once it was builtJohannes Schindelin2019-10-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In b18ae14a8f6 (vcxproj: also link-or-copy builtins, 2019-07-29), we started to copy or hard-link the built-ins as a post-build step of the `git` project. At the same time, we tried to copy or hard-link `git-remote-http.exe`, but it is quite possible that it was not built at that time. Let's move that latter task into a post-install step of the `git-remote-http` project instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | contrib/buildsystems: fix Visual Studio Debug configurationAlexandr Miloslavskiy2019-09-281-7/+8
|/ | | | | | | | | | | | | | | | | | | | | | | | | Even though Debug configuration builds, the resulting build is incorrect in a subtle way: it mixes up Debug and Release binaries, which in turn causes hard-to-predict bugs. In my case, when git calls iconv library, iconv sets 'errno' and git then tests it, but in Debug and Release CRT those 'errno' are different memory locations. This patch addresses 3 connected bugs: 1) Typo in '\(Configuration)'. As a result, Debug configuration condition is always false and Release path is taken instead. 2) Regexp that replaced 'zlib.lib' with 'zlibd.lib' was only affecting the first occurrence. However, some projects have it listed twice. Previously this bug was hidden, because Debug path was never taken. I decided that avoiding double -lz in makefile is fragile and I'd better replace all occurrences instead. 3) In Debug, 'libcurl-d.lib' should be used instead of 'libcurl.lib'. Previously this bug was hidden, because Debug path was never taken. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* vcxproj: also link-or-copy builtinsJohannes Schindelin2019-07-291-0/+3
| | | | | | | | | | | | | | | | | The default location for `.exe` files linked by Visual Studio depends on the mode (debug vs release) and the architecture. Meaning: after a full build, there is a `git.exe` in the top-level directory, but none of the built-ins are linked.. When running a test script in Git Bash, it therefore would pick up the wrong, say, `git-receive-pack.exe`: the one installed at the same time as the Git Bash. Absolutely not what we want. We want to have confidence that our test covers the MSVC-built Git executables, and not some random stuff. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* msvc: add a Makefile target to pre-generate the Visual Studio solutionJohannes Schindelin2019-07-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* contrib/buildsystems: add a backend for modern Visual Studio versionsJohannes Schindelin2019-07-291-0/+385
| | | | | | | | | | | | | | | | | | | | Based on the previous patches in this patch series that fixed the generator for `.vcproj` files (which were used by Visual Studio prior to 2015 to define projects), this patch offers to generate project definitions for neweer versions of Visual Studio (which use `.vcxproj` files). To that end, this patch copy-edits the generator of the `.vcproj`. In addition, we now use the `vcpkg` system which allows us to build Git's dependencies (e.g. curl, libexpat) conveniently. The support scripts were introduced in the `jh/msvc` patch series, and with this patch we initialize the `vcpkg` conditionally, in the `libgit` project's `PreBuildEvent`. To allow for parallel building of the projects, we therefore put `libgit` at the bottom of the project hierarchy. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* contrib/buildsystems: handle options starting with a slashJohannes Schindelin2019-07-291-1/+1
| | | | | | | | | | | | | | | With the recent changes to allow building with MSVC=1, we now pass the /OPT:REF option to the compiler. This confuses the parser that wants to turn the output of a dry run into project definitions for QMake and Visual Studio: Unhandled link option @ line 213: /OPT:REF at [...] Let's just extend the code that passes through options that start with a dash, so that it passes through options that start with a slash, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* contrib/buildsystems: also handle -lexpatJohannes Schindelin2019-07-291-0/+2
| | | | | | | This is a dependency required for the non-smart HTTP backend. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* contrib/buildsystems: handle libiconv, tooJohannes Schindelin2019-07-291-0/+2
| | | | | | | | | | Git's test suite shows tons of breakages unless Git is compiled *without* NO_ICONV. That means, in turn, that we need to generate build definitions *with* libiconv, which in turn implies that we have to handle the -liconv option properly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* contrib/buildsystems: handle the curl library optionPhilip Oakley2019-07-291-1/+3
| | | | | | | | | | Upon seeing the '-lcurl' option, point to the libcurl.lib. While there, fix the elsif indentation. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* contrib/buildsystems: error out on unknown optionJohannes Schindelin2019-07-291-0/+2
| | | | | | | | | | | | | One time too many did this developer call the `generate` script passing a `--make-out=<PATH>` option that was happily ignored (because there should be a space, not an equal sign, between `--make-out` and the path). And one time too many, this script not only ignored it but did not even complain. Let's fix that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* contrib/buildsystems: optionally capture the dry-run in a filePhilip Oakley2019-07-291-0/+10
| | | | | | | | | | | | Add an option for capturing the output of the make dry-run used in determining the msvc-build structure for easy debugging. You can use the output of `--make-out <path>` in subsequent runs via the `--in <path>` option. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* contrib/buildsystems: redirect errors of the dry run into a log filePhilip Oakley2019-07-291-1/+6
| | | | | | | | | | | | | | | | | | | | | Rather than swallowing the errors, it is better to have them in a file. To make it obvious what this is about, use the file name 'msvc-build-makedryerrors.txt'. Further, if the output is empty, simply delete that file. As we target Git for Windows' SDK (which, unlike its predecessor msysGit, offers Perl versions newer than 5.8), we can use the quite readable syntax `if -f -z $ErrsFile` (available in Perl >=5.10). Note that the file will contain the new values of the GIT_VERSION and GITGUI_VERSION if they were generated by the make file. They are omitted if the release is tagged and indentically defined in their respective GIT_VERSION_GEN file DEF_VER variables. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status