Re: ./configure fails to link test program due to missing dependencies

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> I'm not really sure whether distros _do_ actually use autoconf. Checking
> a few distros:
>
>   - Arch doesn't.
>   - Cygwin uses autoconf.
>   - Debian doesn't.
>   - FreeBSD uses autoconf.
>   - Gentoo doesn't.
>   - NixOS uses autoconf.
>   - OpenBSD uses autoconf.
>   - Ubuntu doesn't.
>
> So basically, we'd be making the life harder of anybody who doesn't
> conform to the "standard" way of doing things in Linux, which I think is
> not exactly a nice thing to do.

If we stopped shipping configure (in our tarballs) and configure.in
(in the sources), would distros in the above list that do currently
use autoconf be able to build purely by having reasonable setting in
config.mak.uname already?

> And that's why I think we should have an alternative way to configure
> and build Git that can act as a replacement for autoconf, with my vote
> going to either CMake or Meson.

I guess the above question from me is a semi- tongue-in-cheek vote
for config.mak.uname as that alternative way.

> They are a proper replacement for autoconf that makes the
> downstream maintainer's jobs easier while also bringing additional
> features to the table that we don't currently have.
>
> Eli makes a couple of good remarks in [1] about things that both CMake
> and Meson bring to the table in addition to that, while also mentioning
> some of the benefits of Meson over CMake.
>
> I would be okay to make Git work with such a build system myself. The
> current CMake build instructions can be used to _build_ Git, but AFAIU
> they cannot yet run the Git test suite. Dscho pointed me to a couple of
> patches from Ævar that work into this direction, and I'd be happy to
> revive them. I'd also be okay with picking Meson over CMake if that is
> what people want. But my ultimate goal would then be that we have at
> least one CI job build and test against such a build system and give it
> the "official blessing" as an alternative way to build Git.

I already said that having to support two is better than having to
support three in another thread ;-).  If adding the fourth would
allow us to drop all other three eventually, that would be nice.

Our dependance of heavy use of GNU-ism in our Makefiles makes an
argument that make is the common denominator a fairly weak one, so
the single one that eventually we use does not have to be "make",
but it has to be something available widely and easy to learn.

Thanks.