On Tue, 17 Nov 2020 at 13:33, Brecht Van Lommel via Bf-committers <bf-committers@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. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
