Re: GIT on MinGW problem

From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: May 26, 2007, 22:53 UTC
Message-ID: <4658BA64.2050904@xs4all.nl>
In-Reply-To: <Pine.LNX.4.64.0705262318190.4648@racer.site>

Johannes Schindelin escreveu:

Show 15 quoted lines

>>> * git version reports just:
>>>
>>> 	git version -dirty
>>>
>>> Since git-gui parses the output of git version, but does not expect it
>>> to be of this format, and fails with an error message that it cannot
>>> parse the version.
>> My biggest problem is that the makefiles of git are an unmitigated
>> disaster, and there seems to be little interest in solving this
>> problem. For example, my suggestion to introduce autoconf was met with
>> derision.
> 
> Well, I would not call it derision. But many people have had bad 
> experience with that big mess which is autoconf, so we were more than 
> reluctant to do it.

autoconf is not that big a mess, but it is a macrolanguage, which does come with its pitfalls. Automake and libtool are the messy things, and I prefer to stay away from them as far as possible.

The point of autoconf is to generate a hyper-portable script that deals with all the different flavors of shell breakage. For the user it simplifies compiling packages enormously, which IMO should be the guiding concern if you like to have users.

For a pretty run-of-the-mill tool like git (dependency wise), it should be easy to write a working configure.in.

My favorite approach is: use autoconf to generate

 - config.h
 
 - config.make

All settings that force recompile should be in config.h, and standard C methods to track dependencies will take care of the recompilation when anything changes. The main Makefile includes config.make, and contains all configurable settings. The Makefile only needs to be edited by developers. Require GNU Make so you can write sane makefiles.

Instead, we have a Makefile that relies on an esoteric combination of perl and shell scripting inside Makefiles.

Also, the Makefile says.

  # Shell quote (do not use $(call) to accommodate ancient setups);

I think it would be better to have a clearly defined list of optional and required dependencies with version numbers, and then stand by that. For example, Make uses a completely autoconf/libtool based compile process, and is easy to compile. I think it would be reasonable to require a recent make, say 3.80, and then use its features.

Show 6 quoted lines

> In the meantime, we do have a configure.ac, though. In general, you do not 
> have to run it, but you can if "make" does not work out of the box.
> 
> I have to admit that it is unclear to me what are the problems with the 
> Makefile with regards to gub. I think I will just bite the apple, and 
> download that beast to try it myself.

>From what I recall, it tries to be too clever in detecting changes

of the make command line, forcing a recompile (possibly with erroneous paths) during the

  make install

I might be mistaken, though. I tried to get something up as fast as possible.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen