Skip to content

Commit 7020f21

Browse files
chriscoolchriscool
committed
rn-118: add Meson build system article
1 parent 617ac89 commit 7020f21

File tree

1 file changed

+132
-2
lines changed

1 file changed

+132
-2
lines changed

‎rev_news/drafts/edition-118.md‎

Lines changed: 132 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -25,9 +25,139 @@ This edition covers what happened during the months of November and December 202
2525
### Reviews
2626
-->
2727

28-
<!---
2928
### Support
30-
-->
29+
30+
+ [./configure fails to link test program due to missing dependencies](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/)
31+
32+
Last September Henrik Holst reported an issue when trying to compile
33+
Git 2.44.0 with HTTPS/curl support on LFS 12.1. The 'configure' script
34+
failed to detect libcurl's dependencies properly when trying to link
35+
statically.
36+
37+
The issue occurred because the 'configure' script only used the
38+
`-lcurl` build flag without running `pkg-config --libs libcurl` to
39+
add build flags for dependencies like `zstd` that libcurl
40+
needs. Henrik found that manually setting the LDFLAGS environment
41+
variable to include build flags for all dependencies (like `-lcurl
42+
-lssl -lcrypto -lzstd -lbrotlidec -lz`) allowed the build to
43+
succeed. This sparked a broader discussion about Git's build system
44+
situation.
45+
46+
Looking at 'configure.ac', Junio Hamano, the Git maintainer, noted
47+
that `pkg-config` isn't used at all, instead `curl-config --libs` is
48+
used to detect curl's flags. Even if the 'configure' script was
49+
added early in the history of the Git project, Junio said it was an
50+
afterthought and nobody has considered "upgrading" from
51+
`curl-config` to `pkg-config` for dependency detection.
52+
53+
In fact, our own Jakub Narębski
54+
[initially added the 'configure' script](https://lore.kernel.org/git/200607030156.50455.jnareb@gmail.com/)
55+
back in 2006 to make it much easier to create RPM spec files when
56+
compilation follows traditional `configure && make && make install`
57+
steps.
58+
59+
brian m. carlson replied to Junio that users shouldn't statically
60+
link libcurl or OpenSSL at all, as this creates security issues.
61+
With static linking, security updates to these libraries would
62+
require recompiling Git to take effect. In contrast, dynamic linking
63+
allows security updates to be applied as soon as a new Git process
64+
is spawned.
65+
66+
Patrick Steinhardt replied to Junio suggesting it might be time to
67+
reconsider Git's three build systems
68+
([GNU Make](https://www.gnu.org/software/make/),
69+
[Autoconf](https://www.gnu.org/software/autoconf/), and
70+
[CMake](https://cmake.org/)). He proposed potentially dropping
71+
Autoconf and making CMake officially supported, or switching to
72+
[Meson](https://mesonbuild.com/) as an alternative.
73+
74+
CMake was [added more recently in 2020](https://lore.kernel.org/git/pull.614.git.1587700897.gitgitgadget@gmail.com/)
75+
by Sibi Siddharthan as a third build system with the main goal of
76+
improving the build experience for developers on Windows.
77+
78+
Soon after Patrick's reply, the Git Contributors' Summit happened
79+
and the
80+
["Modern Build System" topic](https://lore.kernel.org/git/Zu2E3vIcTzywWOx3@nand.local/)
81+
was discussed there. Patrick Steinhardt raised concerns about
82+
maintaining three different build systems while others were
83+
concerned about having good platform support and good Windows
84+
developer experience. This led to an extensive discussion about
85+
the merits of different build systems in the thread started by
86+
Henrik.
87+
88+
Eli Schwartz, the Meson maintainer, made a detailed case for
89+
preferring Meson over CMake, citing various CMake pain points and
90+
limitations. Phillip Wood agreed with Patrick about getting rid of
91+
Autoconf, but raised the importance of Visual Studio integration,
92+
since CMake was originally added to improve the Windows developer
93+
experience. Johannes Schindelin, alias Dscho, emphasized that
94+
CMake's deep Visual Studio integration was crucial for Windows
95+
developers and cautioned against switching to alternatives that
96+
would make the Windows experience worse. It appeared that Visual
97+
Studio has Meson support via plugins though, which alleviated some
98+
concerns.
99+
100+
Paul Smith, the GNU Make maintainer, noted that requiring additional
101+
build tools like Meson, which are not yet often used and require
102+
some other dependencies, like Python3 for Meson, adds friction,
103+
though he acknowledged that for Git specifically this may be less of
104+
a concern given its existing dependencies.
105+
106+
Junio seemed to agree that adding support for a fourth build system
107+
would be worth it if it would allow the project to drop all other
108+
three build systems eventually. He said the new build system would
109+
have "to be something available widely and easy to learn".
110+
111+
Patrick came up later in October with a
112+
[21 patch long RFC series](https://lore.kernel.org/git/cover.1727881164.git.ps@pks.im/)
113+
to add support for the Meson build system with the goal of
114+
eventually replacing the current three build systems.
115+
116+
There were a number of iterations on that series. Among the many
117+
comments, Taylor Blau asked about the eventual goals of the series
118+
and plans for CMake support. He noted that CMake support in contrib/
119+
was in an awkward position, neither fully supported nor properly
120+
maintained out-of-tree. He was concerned about having to maintain
121+
three build systems simultaneously during any transition period.
122+
123+
David Aguilar expressed concerns about Python being a dependency
124+
through Meson. Eli replied that muon, a C99 implementation of Meson,
125+
could be used instead and demonstrated it working with Git's build.
126+
127+
Jeff King, alias Peff, asked about reliability for bisecting and
128+
whether out-of-source builds would work correctly when moving
129+
between commits. He also requested better documentation of common
130+
developer workflows with Meson compared to Make.
131+
132+
Junio discussed the need to maintain build system compatibility
133+
during any transition period. He noted that many of the Makefile
134+
options were added over time for good reasons and dropping support
135+
for them would need careful consideration.
136+
137+
A number of other developers participated in the reviews. Ramsay
138+
Jones tested the patches on various platforms including
139+
Cygwin. Phillip Wood reviewed CMake-related changes and provided
140+
technical feedback. Johannes Sixt commented on changes to the
141+
gitk-git subtree. Your own Christian Couder provided feedback on the
142+
documentation.
143+
144+
Over the iterations, Patrick updated the series to improve
145+
documentation, fix conflicts with in-flight patches, and address the
146+
various technical concerns raised during review.
147+
148+
Eventually the
149+
[version 11 of the patch series](https://lore.kernel.org/git/20241206-pks-meson-v11-0-525ed4792b88@pks.im/)
150+
was merged and will be part of Git v2.48.0 that should be released
151+
in the next few weeks. It should be a properly supported modern
152+
build system that can be faster and more easily configurable than
153+
the three existing ones which will hopefully get deprecated over
154+
time.
155+
156+
The merged patch series especially adds
157+
[some documentation](https://lore.kernel.org/git/20241206-pks-meson-v11-24-525ed4792b88@pks.im/#Z31meson.build)
158+
to help build Git with Meson and
159+
[a build system comparison](https://lore.kernel.org/git/20241206-pks-meson-v11-23-525ed4792b88@pks.im/#Z31Documentation:technical:build-systems.txt)
160+
that might be interesting to read.
31161

32162
<!---
33163
## Developer Spotlight:

0 commit comments

Comments
 (0)