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

From: Eli Schwartz <eschwartz@gentoo.org>
Date: Sep 24, 2024, 13:59 UTC
Message-ID: <b6b131cb-683c-4140-9769-290b622721e1@gentoo.org>
In-Reply-To: <ZvKsH1Ct-YwBPA_f@pks.im>

On 9/24/24 8:10 AM, Patrick Steinhardt wrote:

Thanks for the CC to this interesting thread. :)

Show 33 quoted lines

> On Wed, Sep 18, 2024 at 03:39:13PM -0700, Junio C Hamano wrote:
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>>
>>> 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.
>>
>> While I would agree that two is better than having to support three
>> build procedures, I am not sure how improvement of CMake support
>> needs to be a prerequisite for removal of autoconf.
> 
> I'm mostly coming from the angle that autoconf is likely used by systems
> that are not perfectly supported by our current, static configuration. I
> don't want to make the life of such system integrators harder by having
> to figure out what kind of arcane functions they have to set manually
> now to make things build on their platform again.
> 
> 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.

I think we'd probably like to use the configure script rather than the raw Makefile, if the configure script was supported.

It would fix things like git failing to cross-compile because curl-config doesn't work for that, assuming that --

Oh yeah, the configure script isn't maintained well and doesn't use pkg-config. :)

See e.g. https://bugs.gentoo.org/738218 which mentions pkg-config, even.

Show 5 quoted lines

> 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. 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.

Let's say, rather, that they are an alternative for autoconf. And one of the good qualities of them as an alternative for autoconf is that you can actually build on Windows, without needing a mingw toolchain to run a shell script.

An actually maintained autoconf script makes the downstream maintainer's job easier in all cases...

... and also makes the upstream maintainer's job easier in some ways and harder in other ways, because autoconf is hard/annoying to get right as a maintainer. This is due to the complexities of m4 and mixing that inline into "m4sh" -- which was a logical tradeoff in the past, when Windows wasn't as relevant and the GNU project wanted to design a build system that maximized the benefits for end users, including "do not need to install any software to run ./configure", even if that sometimes meant making maintainers' jobs harder. I've never seen a project with a *well-maintained, correctly written* autotools build system where the *unix* end users had complaints about the use of autotools. The complaint is inevitably that autotools wasn't correctly used

Still I would prefer meson over autotools any day of the week. I'd also prefer autotools over cmake, mind you.

Show 12 quoted lines

> 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.

Like, erm, many people :D I spend vast portions of my day inside git. I am not very good at C, though -- and the likelihood of git being completely rewritten in python is quite low -- so I generally do not try very hard to repay that by getting involved in git development (I have some humble patches consisting of a single patch series, which I do feel pretty proud of since it enabled a very useful workflow, but still: ultimately amounts to a one-off event).

I do know build systems pretty well though! :) And I'd be happy to collaborate on Meson and help maintain the build system support in the long term, assuming the consensus is that people think it would be a neat idea to add meson support (regardless of whether it serves as a primary or secondary build system).

Although I'm uninterested in personally working on cmake, as you probably predicted.

-- 
Eli Schwartz
Gentoo Developer and Meson Build maintainer