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.
True, but if you read the article the point is clearly not about source code vs non-source configuration. There’s an implicit assumption that source code is something the developer will be modifying as time goes on, but the real point is, “Don’t make users merge changes.”
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.
True, but if you read the article the point is clearly not about source code vs non-source configuration. There’s an implicit assumption that source code is something the developer will be modifying as time goes on, but the real point is, “Don’t make users merge changes.”