1. 10
  1.  

  2. 5

    The reality is that maintaining portability to alternate environments is an ongoing cost.

    This post lacks nuance; it’s trying to make a general a statement about a problem that varies between projects. There are a bunch of options:

    1. Suggested by the blog post: Don’t take patches for odd architectures unless devs use it and there’s a CI. IMO this is way too dogmatic as general advice.

    2. Write more portable code. This would seem obvious, but there is an over-reliance on #ifdefs in a lot of open source projects. C and C++ have MANY mechanisms to use them portably, and have consistently gained more of them over the decades (e.g. compile time introspection like offsetof(), etc.). The difference between say Lua and CPython is pretty big in this regard, even accounting for the fact that Lua doesn’t have much I/O.

    3. Likewise, when you need platform-specific code, structure your source code so portability isn’t as much of a tax. I think Linux goes to great lengths to separate portable and unportable code, and other projects can do this too, but there is wide variance. Many open source projects in C have a bad structure IMO. They use way too many #ifdefs and not enough interfaces that can be implemented by different architectures.

    So I would say that it’s up to maintainers to weigh the costs and benefits for a particular project. I might be missing the context, but this post is pretty vague and not that helpful IMO. It’s speaking in generalities that aren’t true for every situation.

    1. 4

      Users are both an asset and a liability. People who come to you with portability patches (really, people who come to you with any kind of patches) are generally people who want to be users. Your response to the patch is your response to the prospect of gaining them as users. You can tell potential users that the cost of giving them what they want outweighs the benefit of having them around, but that sounds more like a mature-project move to me than an early-days one.

      1. 2

        Golang is exceptionally unportable, far more so than any other project I know (and I’m including ones like GCC here). Your regular everyday project doesn’t share those problems and works flawlessly on OSes and architectures that the authors never heard about.

        I strongly recommend that people don’t give strong meanings to whether a patch should be accepted and take it as it is. Is it a good patch? if yes, you don’t have to promise you will now forever support big endian strict alignment, you can simply accept the current patch and be welcoming to the contributor.