On Tue, Nov 17, 2020 at 2:40 PM Sybren A. Stüvel via Bf-committers < bf-committers@blender.org> wrote:
> 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". > We need to fix a regression, it doesn't have to be the particular solution in the patch. Eliminating the architecture-specific code is a solution too. > 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. > 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. > I'm talking about processor architectures, not platforms more generally. And if you look at the handful of actual cases where that matters, it's just not that hard to ensure there is a working architecture-independent code path. Either by understanding the behavior, or finding a solution that doesn't require understanding it. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
