Re: GIT on MinGW problem

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