Idea with implementation: config.minimal.h #471
Description
If you want to see the code: https://github.com/nathan-hello/dwm-flexipatch
First, I really appreciate the project. I found it extremely difficult to utilize patches myself,
so this projects allowed me to upgrade my dwm after over a year of being relatively patch-less.
I went through the patches and their corresponding config.def.h entries for a few hours the
other night, and I found it newly frustrating to parse through the many compiler directives
and their branches to know what code was alive and relevant.
My first attempt at fixing this was extracting all of the patch-dependent config.def.h code
into a file in patch/configs/patchname.h as a macro, including the macros, and putting
the macro in the same place I extracted the code from.
This, unsurprisingly, was significantly worse because there's just as many compiler
directives and now all of the code is hidden in some other file.
Another idea is to run gcc -E config.def.h > config.minimal.h which is technically the minimal
code because gcc will strip out all of the compiler directives and leave you with, well, just the
alive and relevant code. But, then there's a new problem where there's code that exists because
of a patch, but you don't know which one because the #if PATCHNAME_PATCH is gone, so we
want to keep some context at the minimum.
So, I got another idea. Take the large config.def.h and strip out all of the unused code and their
directives, and any alive code bring back in the patch/configs/patchname.h
That's exactly what my fork does, at least with some success. It looks fairly decent to my eyes,
but it is chatbot written golang, so obviously not something this project would accept.
I'm writing this as an issue instead of a PR because I know this implementation probably isn't
good enough as well as being written in golang, the commit history is kind of insane because
of the number of commits I did extracting out all of the config.def.h into their own files, and
because I'm not sure if this is what this community wants.
Would a config.minimal.h be something worth pursuing?
Is the config code in a patch/configs/patchname.h file better than having it in the config.def.h?
In my opinion, it would be more maintainable, and possibly better if the files were at
patch/patchname.config.h.
If this is worth figuring out, but patch/configs/ is too much of a change, maybe we just make
a C program that can be called as make minimal-config and that's it. But, I did spend a bunch
of time doing the macro thing, so if that's useful then cool let's go with it.
Again, I really appreciate this project and I would like to know if anyone else has any thoughts
or shares my frustration with config.def.h being difficult to read.