[Bf-committers] Support for 32-bit architectures

[Sybren A. Stüvel]

On Tue, 17 Nov 2020 at 13:33, Brecht Van Lommel via Bf-committers
<bf-committers at blender.org> wrote:
> For example in this specific case it's easy to either:
> * Copy an implementation from another library known to work
> * Switch to using <atomic>
> * Tweak the code to not use 64 bit atomics

I'm assuming you mean D9577 with "this specific case", as that's where
this discussion started before I moved it to this list, and that
you're talking about a problem that 32-bit Linux can't be compiled
because some code uses 64-bit atomic functions that are not defined.
It may be my personal limitation, but somehow I can't combine a patch
where 64-bit atomics are going to be exposed on 32-bit platforms with
"Tweak the code to not use 64 bit atomics".

I tried to steer away from discussing the specifics of that patch
here, though, as I'm more interested in getting a clearer picture of
the general policy on how we handle incompatibilities with unsupported
platforms.

> And if you implement an architecture independent fallback, you can test
> that by disabling the architecture specific code temporarily.
>
> Is that really too much to ask a developer?

Implementing a fallback: if it's clear what a function should do (via
unit tests for example) then no, that's fine.
Understanding how exactly things get unwinded on a specific platform
the developer doesn't have access to -- yes, it is too much.