Re: [dwm] dwm-0.6

Hi,

Sander van Dijk --> dwm (2006-08-02 23:02:42 +0200):
> 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).

I don't see how a patch could break this. A custom config.h won't get
overwritten by hg pull & update, whether such a file exists in the
repository or not.

> It was exactly like that (until 0.6) before Anselm decided to change
> it.

...except that the config.h target had no sources and thus was only
run if config.h did not exist at all. But I see now that this is what
was intended.

> 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 would survive even if there _was_ a config.h in the repository.

> 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).

Same as above...

> 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 don't see anything hidden here (but that's probably because it's
hidden ;-))

> 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.

OK.

> >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).

No. You'd set it in config.mk once after the initial clone, and that's
it. Unless you revert config.mk of course ;-)

> 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.

And the same happens with my patch applied, except that you are not
forced to have your configuration in config.h: you can put it wherever
you want and set the CONFIG variable accordingly. Why I like this:

I run dwm on different hosts. Because of various screen sizes,
keyboards, etc. each of them needs a custom dwm config. One of these
hosts contains the dwm sources, cloned from 10kloc.org with some local
changes and additions, amongst others a custom dwm config file for
each host. These sources are shared between all hosts. My config.mk
contains

        HOST != hostname -s
        CONFIG = config.${HOST}.h

and that's all I need. If one of the config files is modified, config.h
gets automatically regenerated on the relevant host.

I don't think you can do this without my patch. However, I haven't
spent too much time thinking about it...

Are there any drawbacks with the patch?

Cheers, Jukka

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~