904339edbd
Introduce support for the Meson build system, a "modern" meta build
system that supports many different platforms, including Linux, macOS,
Windows and BSDs. Meson supports different backends, including Ninja,
Xcode and Microsoft Visual Studio. Several common IDEs provide an
integration with it.
The biggest contender compared to Meson is probably CMake as outlined in
our "Documentation/technical/build-systems.txt" file. Based on my own
personal experience from working with both build systems extensively I
strongly favor Meson over CMake. In my opinion, it feels significantly
easier to use with a syntax that feels more like a "real" programming
language. The second big reason is that Meson supports Rust natively,
which may prove to be important given that the project may pick up Rust
as another language eventually.
Using Meson is rather straight-forward. An example:
```
# Meson uses out-of-tree builds. You can set up multiple build
# directories, how you name them is completely up to you.
$ mkdir build
$ cd build
$ meson setup .. -Dprefix=/tmp/git-installation
# Build the project. This also provides several other targets like
e.g. `install` or `test`.
$ ninja
# Meson has been wired up to support execution of our test suites.
# Both our unit tests and our integration tests are supported.
# Running `meson test` without any arguments will execute all tests,
# but the syntax supports globbing to select only some tests.
$ meson test 't-*'
# Execute single test interactively to allow for debugging.
$ meson test 't0000-*' --interactive --test-args=-ix
```
The build instructions have been successfully tested on the following
systems, tests are passing:
- Apple macOS 10.15.
- FreeBSD 14.1.
- NixOS 24.11.
- OpenBSD 7.6.
- Ubuntu 24.04.
- Windows 10 with Cygwin.
- Windows 10 with MinGW64, except for t9700, which is also broken with
our Makefile.
- Windows 10 with Visual Studio 2022 toolchain, using the Native Tools
Command Prompt with `meson setup --vsenv`. Tests pass, except for
t9700.
- Windows 10 with Visual Studio 2022 solution, using the Native Tools
Command Prompt with `meson setup --backend vs2022`. Tests pass,
except for t9700.
- Windows 10 with VS Code, using the Meson plug-in.
It is expected that there will still be rough edges in the current
version. If this patch lands the expectation is that it will coexist
with our other build systems for a while. Like this, distributions can
slowly migrate over to Meson and report any findings they have to us
such that we can continue to iterate. A potential cutoff date for other
build systems may be Git 3.0.
Some notes:
- The installed distribution is structured somewhat differently than
how it used to be the case. All of our binaries are installed into
`$libexec/git-core`, while all binaries part of `$bindir` are now
symbolic links pointing to the former. This rule is consistent in
itself and thus easier to reason about.
- We do not install dashed binaries into `$libexec/git-core` anymore,
so there won't e.g. be a symlink for git-add(1). These are not
required by modern Git and there isn't really much of a use case for
those anymore. By not installing those symlinks we thus start the
deprecation of this layout.
- We're targeting Meson 1.3.0, which has been released relatively
recently November 2023. The only feature we use from that version is
`fs.relative_to()`, which we could replace if necessary. If so, we
could start to target Meson 1.0.0 and newer, released in December
2022.
- The whole build instructions count around 3300 lines, half of which
is listing all of our code and test files. Our Makefiles are around
5000 lines, autoconf adds another 1300 lines. CMake in comparison
has only 1200 linescode, but it avoids listing individual files and
does not wire up auto-configuration as extensively as the Meson
instructions do.
- We bundle a set of subproject wrappers for curl, expat, openssl,
pcre2 and zlib. This allows developers to build Git without these
dependencies preinstalled, and Meson will fetch and build them
automatically. This is especially helpful on Windows.
Helped-by: Eli Schwartz <eschwartz@gentoo.org>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
||
|---|---|---|
| .. | ||
| static | ||
| GITWEB-BUILD-OPTIONS.in | ||
| INSTALL | ||
| Makefile | ||
| README | ||
| generate-gitweb-cgi.sh | ||
| generate-gitweb-js.sh | ||
| gitweb.perl | ||
| meson.build | ||
README
GIT web Interface ================= From the git version 1.4.0 gitweb is bundled with git. Build time gitweb configuration ------------------------------- There are many configuration variables which affect building gitweb (among others creating gitweb.cgi out of gitweb.perl by replacing placeholders such as `++GIT_BINDIR++` by their build-time values). Building and installing gitweb is described in gitweb's INSTALL file (in 'gitweb/INSTALL'). Runtime gitweb configuration ---------------------------- Gitweb obtains configuration data from the following sources in the following order: 1. built-in values (some set during build stage), 2. common system-wide configuration file (`GITWEB_CONFIG_COMMON`, defaults to '/etc/gitweb-common.conf'), 3. either per-instance configuration file (`GITWEB_CONFIG`, defaults to 'gitweb_config.perl' in the same directory as the installed gitweb), or if it does not exists then system-wide configuration file (`GITWEB_CONFIG_SYSTEM`, defaults to '/etc/gitweb.conf'). Values obtained in later configuration files override values obtained earlier in above sequence. You can read defaults in system-wide GITWEB_CONFIG_SYSTEM from GITWEB_CONFIG by adding read_config_file($GITWEB_CONFIG_SYSTEM); at very beginning of per-instance GITWEB_CONFIG file. In this case settings in said per-instance file will override settings from system-wide configuration file. Note that read_config_file checks itself that the $GITWEB_CONFIG_SYSTEM file exists. The most notable thing that is not configurable at compile time are the optional features, stored in the '%features' variable. Ultimate description on how to reconfigure the default features setting in your `GITWEB_CONFIG` or per-project in `project.git/config` can be found as comments inside 'gitweb.cgi'. See also gitweb.conf(5) manpage. Web server configuration ------------------------ Gitweb can be run as CGI script, as legacy mod_perl application (using ModPerl::Registry), and as FastCGI script. You can find some simple examples in "Example web server configuration" section in INSTALL file for gitweb (in gitweb/INSTALL). See "Webserver configuration" and "Advanced web server setup" sections in gitweb(1) manpage. AUTHORS ------- Originally written by: Kay Sievers <kay.sievers@vrfy.org> Any comment/question/concern to: Git mailing list <git@vger.kernel.org>