Understanding the dwm patching process

jackmuc · 2023-07-26 12:46:08

Most patches will edit `conf.def.h` which is ignored when the recommended `config.h` is present - so obviously when you `sudo make clean install`, nothing changes

You could just make all your new changes and patches in `config.def.h` and delete the now-old `config.h` before each clean install but I feel that's missing the point?

Or should I be changing the paths in the .diff to `config.h`?

I've searched and searched, and I've tested and experimented with it in many different ways, but I'm still very new and learning and so can only go so far really and would really appreciate any guidance

seth · 2023-07-26 14:05:50

https://dwm.suckless.org/customisation/ wrote:

What is config.h?
config.h is a source code file which is included by dwm.c, the main dwm source code module. It serves as the configuration file for all of dwm's features, e.g., application placement, tags, and colours. A vanilla download of dwm will contain a file called config.def.h, a template you can use to create your own config.h file. To start customising dwm, simply copy config.def.h into config.h before you run make.

You get dwm, patch it, copy the resulting config.def.h to config.h, make your own adjustments to that (manually or eg. w/ a local patch) and build dwm.

jackmuc · 2023-07-26 14:39:59

But what about the next patch? If I've made any of my own adjustments to config.h after the inital patch, then isn't it redundant to patch config.def.h since it's out of sync?

It feels like the logical step would be to patch config.h but I know it must be a fallacy since all the patches patch config.def.h instead

What am I missing if what I do is this:

1. download dwm
2. before build, make personal adjustments in config.def.h
3. build, and config.h is created with my adjustments
4. download patch
5. patch config.def.h and build, all changes copied over to config.h
6. make more personal adjustments in config.def.h and build, all changes copied

It feels wrong to make changes to config.h since it'll just mean that config.def.h would be outdated when it comes time to apply a patch

Or is it just convention to realease patches for .def.h and you really do need to just figure it out yourself?

Thanks

p.s. hope this isn't taken as argumentative. I'm just asking questions to understand - I know I'm missing something

Trilby · 2023-07-26 14:47:36

Long story short: do whatever works for you. The patches published online may need adjustment to suit your preferred workflow.

jackmuc wrote:

It feels wrong

Well, their software may suck-less*, but their ridiculous way of using "config.def.h" and hackish makefiles could not possibly suck more (okay, it could ... if they used cmake). Consider the patches as informational or as example / demonstrations. You need not try to contort your use of the software into what was expected by the patch authors - adjust the patches to work for you.

You will need to adjust some patches anyways if you intended to apply several of them.

*for the record, I had long been a fan of suckless - until I reviewed dwl, that thing is a total mess. But even when I was using dwm / st and was quite sold on suckless projects, I already thought their approach to building software (e.g., with config.def.h files) was total nonsense. Sometimes they try to get too "creative".

Last edited by Trilby (2023-07-26 14:50:11)

seth · 2023-07-26 14:56:04

1,4,5,{2|3|6}

An existing config.h is not supposed to be overwritten by "make", only by an explicit "make config.h" (what literally just copies config.def.h over)

Personal changes to config*h (wherever you opt to apply it, it ultimately doesn't matter except that editing config.h leaves you a "clean" config.def.h to resort to) are like writing the config file for dwm.
It's the last step before running the compiler.
Otherwise patches are just patches to the code.

That being said:

you really do need to just figure it out yourself

There's also no guarantee for patches to he collision-free and there's a good chance that you *have* to revisit the config.h manually when applying many patches to get the thing to build itfp.

jackmuc · 2023-07-26 18:32:20

Thank you both for sharing your knowledge and for the context also, Trilby - I feel reconciled, much appreciated

Arch Linux

#1 2023-07-26 12:46:08

Understanding the dwm patching process

#2 2023-07-26 14:05:50

Re: Understanding the dwm patching process

#3 2023-07-26 14:39:59

Re: Understanding the dwm patching process

#4 2023-07-26 14:47:36

Re: Understanding the dwm patching process

#5 2023-07-26 14:56:04

Re: Understanding the dwm patching process

#6 2023-07-26 18:32:20

Re: Understanding the dwm patching process

Board footer