Subject: Re: [RFC PATCH] Makefile: Turn off the configure target by default

From: Jakub Narebski <[email-masked]>
Date: Mon, 11 Oct 2010 10:39:58 +0200

On Mon, 11 Oct 2010, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Oct 11, 2010 at 07:47, Michael J Gruber
> <[email-masked]> wrote:
> 
> (CC-ing Jakub Narebski, who maintains configure.ac)

I wouldn't say that I maintain it.  I was one of people who started it,
and I try to keep it from being too bitrotten, by asking to provide
configure test when adding new configure knob to main Makefile.

I am certainly not an expert on autoconf.

> I don't like it. For one this would break build scripts that use `make
> configure && ./configure && ...`. It's also annoying to have to set
> some variable to *really* invoke a target that I just indicated I
> *really* wanted by invoking it in the first place.
> 
> Perhaps a @echo from the configure script itself indicating that it's
> complimentary would be better.
> 
> > For most software packages, untar-autoconf/make configure-configure-make
> > is the preferred way to build the package; not so for Git. But the
> > presence of the make target makes people believe so.
> 
> Unlike in most packages autoconf is strictly complimentary for Git,
> but it usually gives you much better results. Instead of the Makefile
> guessing based on `uname -s` we actually check for features and set
> the config.mak.autogen variables accordingly.

That's why we have it, to be able to check for features, rather than
guess based on operating system and its version.
 
> So it's less likely to break on odd systems, and given that (as you
> point out) mostly everyone has autoconf already recommending it as the
> default would make more sense than the other way around.

But thanks to having ./configure optional step, we can build git also
on platforms that doesn't have autoconf installed (though the same could
be achieved by bundling ./configure script with release tarballs).

> >    On an annecdotical note: When I decided to switch to a dvcs, I failed building
> >    Git (with configure) and tried out hg instead. Imagine!
> 
> What sort of failure? Has it been fixed since then?

-- 
Jakub Narebski
Poland