Re: [dwm] dwm-0.6

On 8/2/06, Jukka Salmi <j+dwm_AT_2006.salmi.ch> wrote:
> I don't know much about mercurial, but why should config.h not survive
> pull & update? It doesn't exist in the remote repository:
It did exist before Anselm changed it's name to config.default.h; in
fact, Anselm did that namechange specifically for that reason (to make
config.h survive a pull and update).

> Hmm, I think the question is whether you keep your personal config
> file as config.h or as e.g. config.sander.h. In the former case the
> current Makefile is fine. In the latter case you probably want config.h
> to be updated whenever you change config.sander.h, and that's what the
> patch does. But you're right, you'd have to set CONFIG=config.sander.h;
> why not use config.mk for this?
It was exactly like that (until 0.6) before Anselm decided to change
it. From what I understand of 'hg log | less', Anselm was getting
tired of always having to manually set CONFIG before compiling. So he
decided to no longer ship a file called config.h, and demand of the
user that he/she manually copied whichever config he/she wants in
place before compiling. Since that means that there is no longer a
config.h in the repo, this implies that a present config.h will
survive. It also means that a normal 'make clean install' from a
release tarball would fail if the user doesn't first copy one of the
configs to config.h (which is the case for 0.6), which sucks. Hence I
came up with a middleroad for this: make 'make' create a config.h from
config.default.h, but _only_ when no config.h yet exists. This makes
'make clean install' from a release tarball work, _and_ it gives
Anselm his wanted behavior (being able to keep a custom config.h that
doesn't get overwritten on pull & update).

What your patch does is functionally equivalent to the situation
before 0.6, except that the mechanics are hidden deeper in the build
process (thus less obvious); I agree that setting CONFIG in config.mk
would be better than setting it in the Makefile; the point of the
namechange (config.h -> config.default.h) however was to get rid of
the CONFIG variable, not to reintroduce it in a deeper hidden place.

> And if CONFIG is not set, config.default.h is used, thus current
> behaviour is retained.
Yes, but that's beside the point. With that approach, you'd still have
to do something special _each_time_ you pull & update (setting CONFIG,
either in the Makefile or with 'make clean install CONFIG=blabla).
With the current approach, you just put your configuration in config.h
_once_, and after that you can just do 'make clean install' after a
pull & update. In other words, 'make clean install' will use a custom
config.h if present, or automagically create a default one if not.

Greets, Sander.
Received on Wed Aug 02 2006 - 23:02:46 UTC