[haiku] Re: Open Source Games


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
>   
sys.platform returns more or less what os.name does . In fact os.name is
set according to sys.platform on init time. Therefore the two are
equivalent.
> Regarding default includes, toolchain setup and so on...
> http://scons.org/wiki/FrequentlyAskedQuestions#head-e0ce82e9fe5e40156e31f494e732b8108762d689
>
>   
The key here is ***so it can't find a program that has been installed in
a "non-standard" location unless you tell it how***. Only if the tools
you need are not where they should be according to os.name then you have
to set it on your own. By default SCons has to compile out of the box on
a system and especially provide the proper include/lib path so the
compiler works. Otherwise there would be no need for a platform
independent tool if it leaves all work to you. Besides as mentioned
above os.name yields "posix" in Haiku-Alpha and this means the following:

Linux: os.name="posix", include="/usr/include"
Haiku: os.name="posix", include="/boot/develop/headers"

You see where the problem comes from? If you can only rely on the
platform detection of SCons then in this case it is impossible to tell
what include path to use. If this would be the way to go we would end up
in a dead end. This is why SConcs has to know this for the developer as
long as you stick to the standard locations.

Besides the above mentioned link refers to propagating the PATH env
variable. The problem here though are the include and lib path which are
platform and often also distribution specific.
> 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.
>   
Besides I should note that I work with SCons-1.2.0 not 1.0.1 . The two
are somewhat different. I'll see if I can get this rectified hopefully
with a patch.
> 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.
>   
This is correct. The path/include/lib directories though have to be
provided. Everything outside this scope though is up to the developer.
The path is set correctly and works just include/lib doesn't right now.
> 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: