On Sun, Sep 15, 2024 at 09:37:34AM -0700, Junio C Hamano wrote:
> Henrik Holst <henrik.holst@xxxxxxxxxxx> writes:
>
> > If I set LDFLAGS to whatever pkg-config --libs libcurl says on my system (actually: -lcurl -lssl -lcrypto -lzstd -lbrotlidec -lz) then it compiles just fine. If I add LDFLAGS to the configure environment it will accept that test, and then detect, as expected, the pkg-config settings for libcurl.
> >
> > Should not ./configure FIRST check for a pkg-config environment without assuming that even the most trivial curl programs should compile without any additional dependencies like zstd etc?
>
> Looking at configure.ac, pkg-config is not used for any package.
> Specifically for curl, it seems that "curl-config --libs" is used.
>
> Presumably the reason behind the current behaviour is combination of
> (1) ./configure is an after-thought in the build infrastructure for
> this project, (2) pkg-config was not ubiquitous back when autoconf
> support was written for this project, and (3) nobody considered
> "upgrading" our use of "curl-config" and our manual detection of
> dependency detection for other libraries to just use "pkg-config".
I sometimes wonder whether we should move on and discard one of the
three build systems we have: plain GNU Make, autoconf and CMake. And
from these three I'd rather want to throw the autoconf-based thing away:
- The Makefile is probably what most people use, so throwing it out is
a no-go right now.
- CMake is really useful because it has support for IDEs and
alternatives to GNU Make like Ninja, which builds Git way faster
than Makefiles. It also has support for out-of-tree builds, which I
find rather useful.
So is there a path forward to move CMake support out of contrib/, make
it an officially supported way to build Git and then throw away the
autoconf-based infra? I'm not the biggest fan of CMake myself and very
much prefer Meson, but we already have it wired up and thus I'm trying
to be at least a bit pragmatic.
(I'd honestly prefer to end up with a single build system, but also
throwing our Makefiles out would be a step too far at this point in
time.)
Patrick
