Re: Build Failure: GIT-GUI-VARS

On Fri, May 11, 2007 at 10:10:26AM -0700, Junio C Hamano wrote:

I have not been very sympathetic to config.mak from the
beginning, although people seem to want it.  As I try to arrange
variable overrides to be passed from the command line anyway,
I've not used config.mak myself.

[...]

 (3) The volunteer cooks up an improved Makefile, using
     config.mak "non-stock" testers have.

I wonder if we would be better served by moving these sorts of
build-time configuration decisions into the actual make dependency
tree.  E.g., something like:

  openssl.lib: mklib-openssl.sh conf-openssl
    sh mklib-openssl.sh <conf-ssl >openssl.lib

  program: main.o openssl.lib:
    cc -o "$@" main.o `cat openssl.lib`

where conf-openssl specifies the user's preference (either actual
library paths, "auto" for autodetection, or "none" not to use it at
all), and mklib-openssl is a script that converts that into the command
line options for the link.

You can of course do the same with creating a .h file to choose an
implementation (you just make a file that #define's the correct thing).

The nice thing about this approach is that:
  1. You move configuration cruft out of the Makefile, making it much
     easier to read. Instead, you have a series of very small and
     obvious shell scripts.
  2. The dependency chain is actually correct. If I edit conf-openssl,
     then that should trigger a re-link for everything which compiles
     against it.

You can also use this for portability fixes:

  program: main.o strcasestr.o
    cc -o "$@" main.o strcasestr.o

  strcasestr.o choose try_strcasestr.c compat/strcasestr.c
    sh choose try_strcasestr.c compat/strcasestr.c

where choose is a script that compiles and runs some test program and
uses the result to choose a source file to become strcasestr.c. Thus you
_always_ link against strcasestr.o, it's just that sometimes there's an
implementation of strcasestr in it (if required by the platform) and
sometimes it's empty (or an alternate implementation, etc).

I have used this technique many times, and would be happy to be involved
in changing the Makefile. However, it's going to be quite a large
change, and I recognize that this style is not familiar to most people,
so obviously that should be taken into account.

-Peff