From: Phillip Wood <phillip.wood123@gmail.com>
To: Patrick Steinhardt <ps@pks.im>, Junio C Hamano <gitster@pobox.com>
Cc: Henrik Holst <henrik.holst@outlook.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: ./configure fails to link test program due to missing dependencies
Date: Wed, 18 Sep 2024 11:04:54 +0100 [thread overview]
Message-ID: <29c5c9c0-aa61-415a-9cfa-d64a6b946a48@gmail.com> (raw)
In-Reply-To: <ZufjWR6AJM-DIWPR@pks.im>
Hi Patrick
On 16/09/2024 08:50, Patrick Steinhardt wrote:
>
> 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.
We seem to get fairly regular bug reports about the configure script,
presumably because most contributors are using the Makefile. It would
certainly be nice if we could get the CMake support into a state where
we could consider dropping the configure script.
Best Wishes
Phillip
next prev parent reply other threads:[~2024-09-18 10:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-14 22:57 ./configure fails to link test program due to missing dependencies Henrik Holst
2024-09-15 16:37 ` Junio C Hamano
2024-09-15 16:47 ` brian m. carlson
2024-09-16 7:50 ` Patrick Steinhardt
2024-09-18 10:04 ` Phillip Wood [this message]
2024-09-18 22:39 ` Junio C Hamano
2024-09-24 12:10 ` Patrick Steinhardt
2024-09-24 13:59 ` Eli Schwartz
2024-09-24 14:25 ` Paul Smith
2024-09-25 4:36 ` Patrick Steinhardt
2024-09-25 6:02 ` Eli Schwartz
2024-09-25 6:04 ` Patrick Steinhardt
2024-09-26 13:55 ` Phillip Wood
2024-09-26 14:02 ` Patrick Steinhardt
2024-09-27 10:10 ` Phillip Wood
2024-09-26 16:04 ` Eli Schwartz
2024-09-27 10:00 ` phillip.wood123
2024-09-26 16:22 ` Junio C Hamano
2024-09-29 17:56 ` Johannes Schindelin
2024-09-29 18:10 ` Eli Schwartz
2024-09-30 8:50 ` Phillip Wood
2024-09-30 13:57 ` Eli Schwartz
2024-09-30 16:31 ` Junio C Hamano
2024-09-30 16:05 ` Johannes Schindelin
2024-09-25 19:15 ` Patrick Steinhardt
2024-09-25 19:17 ` Patrick Steinhardt
2024-09-24 17:39 ` Junio C Hamano
2024-09-25 15:33 ` Paul Smith
2024-09-26 1:35 ` Eli Schwartz
2024-09-26 19:42 ` Paul Smith
2024-09-24 14:31 ` Eli Schwartz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29c5c9c0-aa61-415a-9cfa-d64a6b946a48@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=henrik.holst@outlook.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).