[Bf-committers] Support for 32-bit architectures

[Sybren A. Stüvel]

On Mon, 16 Nov 2020 at 17:58, Brecht Van Lommel via Bf-committers
<bf-committers at blender.org> wrote:
> The difference is between:
> * Providing active support for a processor architecture
> * Rejecting or fixing code that only builds on a specific processor
> architecture
>
> Developers should not write code which e.g. relies on pointers being 64
> bit, integers being little-endian, or adding an x86_64 intrinsic call
> without the appropriate #ifdefs. That's not something you should wait on
> the community to fix. It's a bug in your code, like a null pointer
> dereference or invalid memory access.

I agree that assumptions on pointer size and endianness are not good,
and that this is something that's usually easily detected. What "the
appropriate #ifdefs" are is already unclear to me, as I have no
experience with intrinsic calls.

To me the important thing here is that it's hard to write correct code
in the first place. This is why we have automated tests and want to
invest more in proper CI. Writing correct code for hardware you don't
have (either directly or indirectly via a buildbot) is even harder. I
think it's objectionable to ask developers to fix problems that they
have no means of reproducing and that occur only on non-supported
platforms. To make things worse, we don't build libraries for these
platforms either, so even if you can tell your compiler to build for
some architecture, you still can't easily attempt a build.

Personally I'm absolutely in favour of something like this:
- Blender-employed devs don't actively work on fixing issues with
unsupported platforms, but also don't intentionally write code that
would break these platforms either.
- Patches are welcome, and testing on the problematic platform is the
responsibility of the patch author. Of course tests are performed by
the reviewer/committer to ensure they don't break supported platforms.

Expressing an intent to not break unsupported platforms is fine, but
asking developers to understand and recognize problems on platforms
they don't have access to and cannot test on, for me that's a step too
far. Again, certain cases are known "cross-platform breakers" and
should be avoided. I'm trying to get the definition clear of where
those cases end, and where "supporting unsupported platforms" begins.

Sybren