Not sure I buy this. If you have a config header file and make backwards incompatible changes to it how is that different to having backwards incompatible changes to any other config system?
I think what the author meant to say is “don’t make breaking changes to your config system”. Maybe it’s common to ignore that when using source code as config; I don’t know.
It’s a bad idea anyway because compile-time options should generally only be for configuring the presence of optional third party dependencies, which you can do automatically. Anything else should be a runtime option.
I think the author’s primary point is, “Merging changes sucks, don’t make your users do that,” with a corollary: if your program loads configuration from a directory that is only populated by the user, there’s nothing to merge and thus never any merge conflicts. Case in point: /etc/polkit-1/rules.d. I can add whatever rules files I want in there and they’re never going to conflict when I update. If PolKit makes breaking changes to the format, it will log errors somewhere and I can look at those errors, look at my rules, and figure out how to fix them. That’s a hell of a lot easier than merging conflicting changes to code/configuration.
Not sure I buy this. If you have a config header file and make backwards incompatible changes to it how is that different to having backwards incompatible changes to any other config system?
I think what the author meant to say is “don’t make breaking changes to your config system”. Maybe it’s common to ignore that when using source code as config; I don’t know.
It’s a bad idea anyway because compile-time options should generally only be for configuring the presence of optional third party dependencies, which you can do automatically. Anything else should be a runtime option.
I think the author’s primary point is, “Merging changes sucks, don’t make your users do that,” with a corollary: if your program loads configuration from a directory that is only populated by the user, there’s nothing to merge and thus never any merge conflicts. Case in point:
/etc/polkit-1/rules.d. I can add whatever rules files I want in there and they’re never going to conflict when I update. If PolKit makes breaking changes to the format, it will log errors somewhere and I can look at those errors, look at my rules, and figure out how to fix them. That’s a hell of a lot easier than merging conflicting changes to code/configuration.That’s totally orthogonal to whether your config is source code or not though.