[haiku] Re: Open Source Games
- From: Michael Weirauch <dev@xxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Sat, 19 Sep 2009 01:22:00 +0200
2009/9/18 Roland Plüss <roland@xxxxxxx>:
> As it turned out the problem had not been the missing environment
> variable. The problem had been a wrong platform. According to the
> modifications you guys made Haiku-Alpha should report "haiku" for
> sys.platform. This is though not the case so "posix" came back. Hence
> subsequent Environment(platform=sys.platform) calls stopped working
> because the newly created environment used the posix init instead of the
> haiku init you guys wrote.
The sys.platform string was chosen to provide a means of future distinction
for Haiku R2 which *might* be overhauled in many aspects. There was no
real opposition to keeping the identifier to 'haiku1'.
> In a SCons build for a complex build with
> nested SConscript files as I am using it you will find many such
> sub-environments. So that's where things broke. Now why? The problem had
> been small but devastating. For some reason sys.platform does not
> resolve to "haiku" as wrote in the Platform/__ini__.py file but it
> actually resolves to "haiku1" ( most probably because of alpha ).
'haiku1' has been chosen for the reasons above. (Which might or might not prove
useful later on or even right now.)
The __init__.py uses string.find() and does not do a string comparison
against 'haiku'.
>Hence
> the test fails sind obviously sys.platform="haiku" is not true so
> "posix" has been returned and the drama took it's course. There are now
> two solutions for this problem:
>
> Solution 1)
> Fix Python to return "haiku" for sys.platform and not "haiku1" as it
> does right now.
>
> Solution 2)
> Modify Platform/haiku.py and replace "haiku" with "haiku1" ( two
> occurances ). Then rename the file Platform/haiku.py to Platform/haiku1.py
>
> I did solution 2 and now everything is working as it should. Includes
> and libraries are now detected as they should be. Pick your solution.
Solution 2 sounds like a plan. But there is for example irix doing the very
same thing as we do. They might actually return irix6 for sys.platform.
The same applies for any other platform found below the os.name ==
'linux' path...
... except cygwin. Any writer of platform-spanning
SConsctruct/SConscript will have to
deal with exactly the fact/issue that sys.platform might/will contain
a versioning
information. One just does not stumble over that "versioning-issue" when using
Windows (win32.py) or GNU/Linux (default posix.py) and using the explicit
construction with sys.platform.
Do you have any special need for constructing the Environment
explicitely with the given sys.platform whereas Environment() will give what
you would expect in the first place?
There is even a bugreport for that explicit construction. Don't get the reason
for the WONTFIX except the false capitalization of PLATFORM, though.
http://scons.tigris.org/issues/show_bug.cgi?id=1469
So, this is getting lengthy and I don't see anything wrong with 'haiku1' nor
any obvious failures in the current state. It's proven well building Blender
on Haiku, and I wouldn't call their SCons environment trivial.
Regards,
Michael
> --
> Yours sincerely
> Plüss Roland
>
> Leader and Head Programmer
> - Game: Epsylon ( http://epsylon.rptd.ch/ ,
> http://www.moddb.com/games/4057/epsylon )
> - Game Engine: Drag(en)gine ( http://dragengine.rptd.ch ,
> http://www.moddb.com/engines/9/dragengine )
> - Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )
>
>
Other related posts:
