(05-06-2021, 02:12 PM)ckester Wrote:

(05-06-2021, 09:49 AM)phillbush Wrote: The chapter then explains where configuration should be read from.
• Run-control files (in /etc and dotfiles in ~/).
• Environment variables.
• Argument options.

This is probably an appropriate place to ask: What do you guys think of suckless-style config.h files and compile-time-only configuration?

It's an approach that will frustrate users who aren't coders (admittedly not the target audience) but I kinda like it from a minimalist perspective.

They're an alternative to run-control or dotfiles for preferences which aren't likely to change between invocations and have the advantage of not requiring parsing routines in the code.

The main disadvantage I can see is, even if all the users are coders capable of making the desired changes themselves, they will each have their own copy of the program. This might not be a problem, however, given the storage space available on most systems today.

Parsing configuration files requires more code. I can see the advantage of using a config.h for a project that privileges simple code. However, the system provides configuration methods that do not require parsing: command-line arguments, environment variables and X resources, solutions which are not explored by suckless tools (except by patches). In my programs, I explore those methods for configuration.

Also, as movq said

Quote:I think config.h only makes sense for programs with very few external libraries.

Which is the case for suckless tools.