[haiku] Re: Open Source Games
- From: Roland Plüss <roland@xxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Fri, 18 Sep 2009 23:34:29 +0200
scott mc wrote:
> On Fri, Sep 18, 2009 at 1:57 PM, Roland Plüss <roland@xxxxxxx> wrote:
>
>> Michael Weirauch wrote:
>>
>>> 2009/9/18 Roland Plüss <roland@xxxxxxx>:
>>>
>>>
>>>> Michael Weirauch wrote:
>>>>
>>>>
>>>>> 2009/9/18 Roland Plüss <roland@xxxxxxx>:
>>>>>
>>>>>
>>>>>
>>>>>> I should have been most probably a bit more specific. It seems to be a
>>>>>> problem with SCons and it's header/library detection routine. I just
>>>>>> installed PNG from a precompiled binary and it fails to find it. Looks
>>>>>> like SCons needs a fix up but for this I need to know first what the
>>>>>> correct locations in Haiku are for the headers/libraries to look for. I
>>>>>> assume /boot/common/include and /boot/common/lib but maybe there are
>>>>>> more than those.
>>>>>>
>>>>>>
>>>>>>
>>>>> Roland,
>>>>> SCons is being initialized with a minimal set of "hints" in the
>>>>> platform initialization
>>>>> file as with every other platform init file. It's told in which paths
>>>>> to find binaries
>>>>> and the glue files for the linker.
>>>>>
>>>>> AFAIU, the rest is up to the developer setting up the SConscripts
>>>>> correctly.
>>>>>
>>>>> If, of course, other platforms toolchains have a wider set of default
>>>>> search and include paths,
>>>>> then one might reconsider providing some more hints to SCons on Haiku
>>>>> by default.
>>>>> But I think it is not necessary. Building blender with the SCons 1.0.1
>>>>> patch from haiku-ports
>>>>> shows no issues at all. (After setting up the blender-specific
>>>>> platform init file)
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Somehow I doubt this is correct because if I run a crossplatform
>>>> SConstruct file straight and it fails to find headers in the system
>>>> headers path then it's not my fault. Unless you expect a crossplatform
>>>> SConstruct to know the system path on all platforms it could be compiled
>>>> for. With Haiku this doesn't even work since os.name returns "posix" so
>>>> you have no way to tell if it's Haiku you compile on right now or Linux
>>>> or some other Unix derivate. So how should you know then if you have to
>>>> look in /boot/develop/headers instead of /usr/include this way?
>>>>
>>>>
>>> I am sure you have far more experience with SCons than I do.
>>>
>>> os.name returning posix is the setting python provides. Determination of the
>>> specific platform is done via sys.platform.
>>> See
>>> http://scons.tigris.org/source/browse/scons/tags/1.0.1/src/engine/SCons/Platform/__init__.py?revision=3540&view=markup
>>>
>>> Regarding default includes, toolchain setup and so on...
>>> http://scons.org/wiki/FrequentlyAskedQuestions#head-e0ce82e9fe5e40156e31f494e732b8108762d689
>>>
>>> And that is why the platform initialization is what it is. Very basic.
>>> If you think that is utterly wrong
>>> you are welcome to file an improved patch at haiku-files.org's SCons
>>> portolog page.
>>>
>>> Nevertheless, I do still think that the FAQ entries say it all and
>>> that is why all platform init
>>> files you see in the 1.0.1 release don't set any system includes at
>>> all. For reference:
>>> http://scons.tigris.org/source/browse/scons/tags/1.0.1/src/engine/SCons/Platform/
>>>
>>> Please don't get me wrong, but for my understanding SCons tries to be
>>> as ignorant as possible
>>> by not knowing anything about a specific platform/operating system
>>> environment unless it is
>>> explicitely told about it. And that is exactly the path the Haiku init
>>> file follows.
>>>
>>> Michael
>>>
>>>
>>>
>> ROFL! Oh god... this is twisted and cranked up. The problem lies even a
>> few levels deeper. There are two possible ways to solve this so somebody
>> of the team tell me which solution is the one you folks want. So first a
>> run-down of what goes down then the two possible solutions.
>>
>> 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. 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 ). 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.
>>
>> --
>>
>
> would "haiku*" or "*haiku*" work? if so then I'd go with that.
>
> As for detecting what directories to use there is a command line
> program called 'finddir', pass it the constants listed in the BeBook
> at it will return that pathname.
> http://www.haiku-os.org/legacy-docs/bebook/BDirectory.html#BDirectory_Constants
>
> Also I believe that SCons was built prior to the alpha release so it
> may or may not need to be rebuilt on the alpha so that it get's the
> right environment set up, that is unless you built you own. Python
> was build with the alpha so it should be fine.
>
>
> -scottmc
>
>
I noticed a little inconsistency. I installed the PNG package which
caused the library and includes to reside in the system wide location
and the /boot/common location. Testing with a lib which only exists in
/boot/common showed the following:
- include files found in /boot/common/include
- lib file not found in /boot/common/lib
Looks like something is off there. /boot/common/include is recognized
and scanned for headers but /boot/common/lib is not recognized nor
scanned for libraries unless added by hand. I can understand if this
place is not looked for but why checking it for headers but not libs?
Rather inconsistent.
--
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:
