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