Hello Carsten,
> Carsten Neumann wrote:
>> Johannes Brunen wrote:
> did you do this for convenience or did it not work otherwise. Using
> python Tools/scons-local/scons.py to invoke scons worked fine for me
> (python has to be in the PATH, of course).
No, only for convenience. Both files just map to the
Tools/scons-local/scons.py script.
I was used to it from the OpenSG 1.8 release.
>> The first problem I did encounter was that the boost filesystem library
>> could not be found. After some investigations I came to the conclusion
>> that
>> there is an error in the scons implementation in file
>> Tools\scons-local\scons-local-1.0.0.d20080826\SCons\Conftest.py. This
>> file
>> contains a function CheckLib() which is called in the context. The
>> result of
>> this function call is responsible for success or failure. Now, this
>> function
>> contains the following line of code ret = context.BuildProg(text,
>> suffix)
>> which gives True or False as result. Yet the CheckLib() function returns
>> ret
>> with the following meaning: "Returns an empty string for success, an
>> error
>> message for failure." This does not match. I added the following line of
>> code after the BuildProg() call: if ret: ret = "" After that the boost
>> library is found appropriately. IMHO, probably all BuildProg() calls are
>> problematic in this file.
>
> hm, strange, I've used VC 9 Express and it worked fine after removing
> 'Exp' from the name of toolset passed to the Boost option (i.e. changing
> 'VC90Exp' to 'VC90').
>
I'm using the professional version of the ms developer studio and I have
build the boost libraries by hand. I build the boost libraries with the
following command:
bjam --toolset=msvc-9.0 debug release threading=multi link=shared
link=static runtime-link=shared stl-security-theater=off stage
(The stl-security-theater flag is for the _SECURE_SCL=0 business. It is
found on the boost mailing list as a proposal from Mat Marcus to the
msvc.jam file.)
I have debugged the scons call to CheckLib and IMHO the BuildProg return
value is not handled correctly.
>> On my wish list is the possiblily of adding to the
>> LINKFLAGS from the command line. Is this yet possible and do I miss it?
>
> I don't think its possible, it's quite a special circumstance...
>
Is that really so special? What if I'm in need for some special Linker flag
necessary in my setup? Build systems should IMHO abstract the build business
but should allow for obsure fine tuning.
>> Next I could not compile because of the new compiler which is not
>> correctly
>> supported by the current scons project. Actually, I did test the very
>> last
>> stable release without success. Therefore I changed the affected scons
>> sources myself. I changed the following two files:
>> Tools\scons-local\scons-local-1.0.0.d20080826\SCons\Tool\msvs.py
>> Tools\scons-local\scons-local-1.0.0.d20080826\SCons\Tool\msvc.py
>> Below you can find these two files for your convenience.
>
> hm, again, it worked fine for me with the express edition. However, I
> also have only one compiler installed ATM.
>
I have a standard msdev professional installation on my machine. Nothing
obsure in this matter. However, I losely follow the scons mailing lists and
there is some discussion about the support of the new vc9 compiler. I took
it pragmatically, I was unable to go with the standard setup (for both
OpenSG 1.8 and 2.0) so I duplicated the vc8 functionality to vc9 in the
msvc.py and msvs.py files. Then I changed this new functionality to the
special particularities of the vc9 setup. So if anyone has similar problems
don't despair give my solution a chance at last. It worked for me.
>> At last I have changed the main SConstruct file for two reasons:
>> 1. I did build all support libraries myself. And the tiff and freetype
>> libraries simply have other names: (tif32 -> libtiff and freetype ->
>> freetype237). It would be nice if I could to this on the command line
>> too.
>
> yeah, this is a pain on windows, there is even less uniformity than on
> linux - there my biggest complaint are the boost libs.
>
I disagree, the boost libraries handle this matter correctly. They admit
that the different compiler and linker options yield different ABI versions
which must be used consistently. Therefore they distinguish the produced
libraries by name. Additionally, they provide auto linking facilities which
free the user from choosing the right
version. It is done automatically. And it worked quite good, imho.
The naming of the other libraries is forced by the build procedure of the
individual libraries. I build them all from scratch and have used the names
I got. I did rebuild them for two reasons. At first, to get the latest
versions. Secondly, to avoid a link dependency problem with the runtime
libraries. In vc8 or vc9 (don't know exactly) ms disposed the single
threaded linking model. This problem could only be solved by changing the
application's link setting to force the exclusion of this dependency. I
didn't liked this way therefore the rebuild with compatible settings.
>> 2. In line 842 I added common_env.Append(CXXFLAGS = "/D_SECURE_SCL=0")
>> in order to allways build with this flag. As you might expect, I would
>> like
>> to do it on the command line...
>
> I started working on redoing the build system and adding a way to add
> compiler options was on the list, but this is currently on halt because
> of more urgent matters.
>
Yes, there are always to many things to do...
>> Ok, now back to the collada error I have encountered. On building
>> OSGFileIO.dll build systems stops due to error. The error states that
>> the
>> following libraries could not be found:
>> l.lib i.lib b.lib c.lib o.libl.lib l.lib a.lib d.lib a.lib 1.lib 4.lib
>> d.lib
>> o.lib m.lib i.lib c.lib o.lib n.lib v.lib _.lib a.lib
>> After looking twice, I saw that this is libcollada14dom and iconv_a.
>> For testing I changed the lines 654-658 to
>
> try changing Source/System/FileIO/Collada/build.info
>
> from:
> libs.extend(collada_option.library)
> libs.extend(xml2_option.library )
>
> to:
> libs.append(collada_option.library)
> libs.append(xml2_option.library )
>
I will do...
>> opts.AddOption(sca_opts.SeparatorOption("\nPackage settings (optional
>> libs)"))
>> for opt in optional_libs_options.itervalues():
>> if opt not in image_format_options.itervalues():
>> print opt.library
>> opts.AddOption(opt)
>>
>> With this I got the following output on running the build script:
>>
>> ['libcollada14dom']
>> freetype237
>> glut32
>> zlib
>> fontconfig
>> X11
>> NVPerfSDK
>> None
>> ['iconv_a', 'libxml2_a']
>>
>> Now, the libraries which are contained in the python lists are
>> problematic.
>> Until now, I could not find the origin of this error. Maybe I have
>> introduced it myself. Any help is appreciated.
>> As a follow up I'm expecting a link failure because my collada libraries
>> are
>> named:
>> libcollada14dom21.lib
>> libcollada14dom21-d.lib
>> But the build says "Checking for C++ library libcollada14dom... (cached)
>>
>> yes"!? Something is wrong here. But one step after the next.
>
> hm, did it find it perhaps in an earlier configure attempt? Right now it
> is not really searching, but takes the value from a cache. Use
> --config=force to have scons redo all configure checks.
>
Don't think so, because I stared from scratch. But I will take a closer
look...
Best,
Johannes
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
