Re: Build Failure: GIT-GUI-VARS

From: Jeff King <peff@peff.net>
Date: May 12, 2007, 00:09 UTC
Message-ID: <20070512000946.GB19282@coredump.intra.peff.net>
In-Reply-To: <7v3b23cmm5.fsf@assigned-by-dhcp.cox.net>

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

Show 9 quoted lines

> 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