Re: GIT on MinGW problem

[Jakub Narebski <jnareb@gmail.com>]

Han-Wen Nienhuys wrote:

> Johannes Schindelin escreveu:

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

Actually we do have configure.ac script; ./configure (result of
"make configure") is not distributed in the tarball I think.
It generates file named not config.make, but config.mak.autogen.
By the way, the .autogen suffix is to distinguish ./configure generated file
from handmade user configureation, but I have no idea why it is config.mak
not config.make. But there is no config.h -- we do not rely on automake and
autoheader.

If you are well wersed in autoconf, feel free to improve our configure.ac
script.
 
> Instead, we have a Makefile that relies on an esoteric combination of
> perl and shell scripting inside Makefiles.

The idea is to be able to get reasonable defaults (depending on system of
course) without needing autoconf, and running quite long on some
platform ./configure script detection...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git