[Bf-committers] Support for 32-bit architectures

[Brecht Van Lommel]

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.


On Mon, Nov 16, 2020 at 4:55 PM Ray Molenkamp via Bf-committers <
bf-committers at blender.org> wrote:

> I've always understood our position to be
>
> - We do not plan to break or remove 32 bit support.
> - Given we don't CI on 32 bit anymore, breakage can sometimes happen
> without us knowing.
> - If external parties supply patches to fix such breakage and they pass
> code review, we merge them. Even if they are for platforms we ourselves do
> not ship. D2860 (haiku OS) is a nice example there.
>
> I'm not sure if that is the official position, but that's my current
> understanding of it.
>
> --Ray
>
> On 2020-11-16 8:36 a.m., Sybren A. Stüvel via Bf-committers wrote:
> > Hello list,
> >
> > Blender 2.80 was the last version of Blender for which 32-bit builds
> > were officially supported. This was announced by Brecht in [1].
> > That announcement was a bit unclear to me, which I let pass because it
> > wasn't that relevant for my position back then. However, now that I'm
> > the Linux platform maintainer, I wouldn't mind if the situation was
> > clarified.
> >
> > In that announcement, Brecht writes:
> >> Blender 2.80 was the last release where we officially support 32 bit
> Windows and Linux builds. [...]
> >> We will continue to support it to the level that we do for example ARM.
> That is we keep the Blender code working independent of the processor
> architecture, particularly for Linux packages. But we don't actively test
> them or release our own builds.
> > This sounds like an impossibility to me: the promise that we keep
> > things working, but without building, or testing. Apparently there is
> > also a distinction between "official support" and "support to some
> > level".
> >
> > The Blender requirements page [2] does list 64-bit as a requirement.
> > But, there is no "last version that supported 32-bit" in the "Previous
> > Versions" section of that page. Also there is no mention of dropping
> > official support for 32-bit architectures in the 2.81 release notes
> > [3].
> >
> > I found out about this unclear situation when looking at a patch that
> > ought to fix an issue on 32-bit platforms [4]. In the discussion on
> > that patch, Brecht writes:
> >> When writing or reviewing code, you ensure that there is always a
> processor architecture independent code path. And if you get a report and
> it turns out such a code path is missing or broken, you fix it. It's the
> same for x86, mips, sparc, etc.
> > This looks like a statement that these platforms are still supported.
> >
> > Personally I would summarize the above as:
> > - Blender Foundation does not provide buildbots for 32-bit platforms.
> > - Developers have to ensure these platforms keep working.
> > - Testing such fixes is unnecessary.
> >
> > I think I'm misunderstanding the situation here, and I wouldn't mind
> > if this was clarified.
> >
> > Sybren
> >
> > [1]:
> https://lists.blender.org/pipermail/bf-committers/2019-August/050124.html
> > [2]: https://www.blender.org/download/requirements/
> > [3]: https://wiki.blender.org/wiki/Reference/Release_Notes/2.81
> > [4]: https://developer.blender.org/D9577
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>