[Bf-committers] New supported platform
ton at blender.org
Sat Sep 10 11:41:18 CEST 2005
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
> 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? :)
> 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
Ton Roosendaal Blender Foundation ton at blender.org
More information about the Bf-committers