First batch of patches for Sparc64 porting effort

[bog-dan-ro]

Hi,

I'm trying to port Vitruvian on sparc64 (BigEndian strictly aligned arch)
This is the first batch, more will come in the following weeks as it seems I'm quite far from getting it running on sparc :).

[Numerio]

Hi, I think It's ok to do this but, for now let's keep it in this PR until it's more complete. I will follow the work and you can submit incremental updates to your branch easily.

A couple of points:

• Even before doing that, if you want the arch to be officially supported, make sure we can actually have a modern debian packaged for sparc64, like a debian derivative that supports it and keeps up-to-date with packages is a good sign of that this is actually possible. Otherwise this work could have it's own place in some semi-official unsupported stuff we're planning out, though this is in very early planning stages.
• Disabling Nexus is really not an option. So that part can't be merged.
• I see you added two public functions to Message.cpp as very general rule of thumb, we don't have an ABI for now to support, but in general we're trying to be as much as we can BeOS/Haiku compatible. So while general "fixes" patches are generally easier to get through, introducing a public method is much more complex. From a fast look seems to me the two functions should be private anyway, and that'd be much less of a problem.

[bog-dan-ro]

Hi,

Thanks for your feedback!

• Debian is my primary linux distro, I'm using it for decades, sadly the sparc64 support is not first class, so I endup with gentoo and I created a small gentoo package for Vitruvian (is in super early stage, nothing shareble). I'm also eyeing https://t2linux.com/ as an alternative.
• I need to optionally disable nexus as I'm creating a separate non-debian package.
• Yeah, I put them temporary in Message.h until I find a better place. These functions are pure templates so they don't have any symbols in the library (can not break the ABI).

I'm trying to port Vitruvian on my sun blade for multiple reasons,but the 2 most important ones are: proper software rendering and good looking UI ;-). BTW, what's your take on AI usage? So far I didn't used it for Vitruvian as I didn't know if you're okay with it, but if is allowed I'd like to make use it from time to time. Of course all the patches will be properly reviewed by.

[Numerio]

Thing is that you'll do a much better favor to the project and long-term support if you started off with a custom kernel and re-building the debian packages. Our deps are about the ones needed by a very minimal distro. Over time it will become increasingly harder to run the thing on stuff that's not our mainline, and generally we don't want a project that's scattered, by it's very own nature, philosophy and direction. I suppose it's ok to start off some already existing platform but my suggestion is to keep in mind the big plan.