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 > > Tracked a bit deeper into this one. Looks like it is not actually the include/lib path that is broken but the conf test in SCons itself. It looks right now like an incorrect parameter is given to the g++ trying to test-compile. Maybe this is because you use gcc2 instead of gcc4 since SCons is build for gcc3/gcc4 to begin with. Most probably a patch to the test routine should fix this. Not to blame the haiku team or anything like this since SCons is rather fickle about such things. -- 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 )