patchMove "-include config.mak" to end of configuration section

This makes it possible to define WITH_SEND_EMAIL etc. in config.mak.

---

 Makefile |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

fe5fece83b2ab0d67a4277d851faf50ad944cff4

Hi,

On Thu, 1 Dec 2005, Timo Hirvonen wrote:

... but it breaks setups where config.mak overrides platform dependent settings...

Hth, Dscho

This makes it possible to define WITH_SEND_EMAIL etc. in config.mak.

Also remove GIT_LIST_TWEAK because it isn't used anymore.

---

 Makefile |   28 ++++++++++++----------------
 1 files changed, 12 insertions(+), 16 deletions(-)

f877acdc3f8c888dd82a1e81ce20c8715e3108e4

Honestly speaking, I'd personally prefer to just get rid of "-include config.mak" from Makefile. If somebody wants to keep her customized set of configuration, she can have her own ./Make script that would look like:

	#!/bin/sh
	make WITH_SEND_EMAIL=YesPlesae NO_EXPAT=NoThanks "$@"

Hi,

On Wed, 30 Nov 2005, Junio C Hamano wrote:

But it is only one line, heck only 20 bytes!

And you can still use your "./Make" method, and it is not widely advertised, and you can override settings from the platform-dependent code, and I feel much better at having my littly config.mak, my precious!

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Hey, don't get so piped up. Timo's patch has already been merged (thanks, Timo).

But think about it a bit.

If you need an override, you have to write down and maintain those YesPlease _somewhere_ yourself anyway, outside what I ship. Either "config.mak" or "Make" script.

If we have '-include' in the Makefile, we need to make a decision if what we are adding to the Makefile should be overridable by that config.mak every time, exactly because whatever is included becomes part of the Makefile. IOW, that "only 20 bytes" adds work for the Makefile maintainer.

"Make" script method is a command line override to the "make" program, which takes precedence and does not have that problem.

On 12/1/05, Junio C Hamano <junkio@cox.net> wrote:

I have even my specific targets in the config.mak (and would actually like to have the default target put before including config.mak, so default call to make is always the same).

Alex Riesen <raa.lkml@gmail.com> writes:

Surely you can do that by having your own "makefile" and include "Makefile" I ship, and run "make", which prefers makefile over Makefile ;-).

On 12/1/05, Junio C Hamano <junkio@cox.net> wrote:

But that is not the same:
 - I can put my targets and variables either before or after Makefile,
not somewhere inbetween
 - I have to work on an especially brain-damaged filesystems, like FAT

Alex Riesen <raa.lkml@gmail.com> writes:

Hmph.  Do you mean something like this?

-- >8 --

On 12/1/05, Junio C Hamano <junkio@cox.net> wrote:

Yes. In fact, that is what I have in my tree :)

Hi,

On Thu, 1 Dec 2005, Junio C Hamano wrote:

In case I did not make it clear: I was not mad or something like that. I only see 3 ways to go about that particular problem:

- maintain your private config.mak
- maintain your private Make (shell script)
- maintain your private Makefile

I actually did the third way for a while, always merging the newest version. But all of a sudden -- when I was working on another project, which *has* a config.mak -- I had the idea to do the first way.

Actually, the second way falls a little bit short for some of my applications: I sometimes override settings in the first part of the Makefile. This is not possible with Make.

As mentioned, with the difference that you just can't override some things in Make.

... which might have another (desired) effect: the structure of the Makefile is better. More organized.

Besides, if you change things in an organized Makefile, you tend to be a little bit more careful where you put things, so the cost of maintaining is not really high (happened to me...).

Hth, Dscho