[Bf-committers] New supported platform

[Ton Roosendaal]

Hi Yomgui,

I'm always pleased hear results of new Blender ports. Afaik, MorphOS  
runs on the Amiga family of hardware? Info on morphos.org is a bit  
confusing, does it run on any PPC computer?

> 1) Blender uses makefile and scons for the build management. But...
>   * makefiles are really bad for an easy maintain.
>   * scons is not ported on MorphOS
>
> So... to accelerate my port I've written some scons-like scripts in
> python and there is only 1 scripts to compile everything for MorphOS
> in blender sources tree (in the root directory, named 'makeall.py').
> It's a poor script, but very efficient! and it uses my 'Boa' (temp.
> name) python module (given with my python - 2.4 port).

Sounds good to me. If its only 1 script, it won't intrude our source  
tree at all. :)

> 2) MorphOS, as Window, is a non-Unix platform, but support in some
> ways POSIX path (not in native, but the shell does the translation).

How's the file paths in MorphOS constructed then?

> To handle this, I've coded 2 news functions in blenlib:
>
> BLI_NativeToPosix() and BLI_PosixToNative()
>
> The purpose of this functions is to convert a native path into a POSIX
> path. each platform should make a port of these functions, and only
> that, to have a file path support.
> But in this case, everywhere in blender sources, the rules is to say:
> "Blender must use POSIX file paths and when a path should be given to
> an external lib or used by the system, it must be passed throught this
> functions". This rule applies to Python too (external lib case).
>
> In future (blender 3 ?) I propose this: have an OSAL (Operating System
> Abstraction Layer) to not have to handle in every source code path
> convertions or I/O operations (like this question: "is opendir()
> existing on my XXX platform?", etc...)
>
> In this osal we found my previous convertion functions, but such thing
> like to read/write files, know information about files (complex stat()
> support), and everything that would be founded linked to the OS (or a
> 'DOS').
>
> This method is a particular benefit to eliminate all dedicated code
> for one platform or another  one... and eliminate all #ifdef WIN32 or
> #ifdef __APPLE__ that complexify the source code readability.

Yes, we definitely should tackle this issue more systematic. The  
current code - with ifdefs - is just too ugly. I don't think we have to  
wait for a mythical 3.0 to be made. :)

We have numerous Windows path issues in Blender, mostly solved quite  
badly. If your code would structure that nicely we'll just add it. Can  
you upload for us a diff of the blenlib file(s)?

Looking at the screenshots at your site; there's an endianess issue  
with the colors of the Ipo (animation) curves. Also the header  
'release' color seems to have an endianess flip.
Endianness is not #ifdeffed in Blender, but there might be exceptions  
in the code for it. As a reference, heck for #ifdef __sgi for example.
And, did you notice the support for amiga iff files that's still  
hanging out in the imbuf code? :)

Best regards,

-Ton-

>
> My last notes: I don't know if such thing are in progress for next
> versions of Blender, but if we want to simplify the code and support
> all platform possible, we should do that! ;-)
>
> Sincerly yours,
> Guillaume ROGUEZ (aka Yomgui on the web ;-)).
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org