Re: GIT on MinGW problem

[Han-Wen Nienhuys <hanwen@xs4all.nl>]

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.

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. 

> 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