• FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    8
    ·
    7 months ago

    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.

    • Ethan@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      ·
      7 months ago

      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.

        • Ethan@programming.dev
          link
          fedilink
          English
          arrow-up
          1
          ·
          7 months ago

          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.”