Hallo Johannes,
Johannes Brunen wrote:
> Hi,
>
> (Ok, now I send this mail for the third time. Something is going wrong
> with my
> acount. Please excuse if this mail does appear multiple times. But I
> have to
> check. Now I'm trying another mail client.)
>
> Last night I have tried the current svn version of OpenSG 2.0 with msvc
> .net
> 2008 sp1 (a.k.a. vc 9). I would like to report what I have learned about
> the
> matter...
>
> At the very first I have had to create the files scons and scons.bat,
> respecitvely, which you can find below.
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).
> I'm using a unix like korn shell (MKS tools). For this shell I wrote a
> small
> convenience helper script for starting the compilation. This can be done
>
> with ms dos batch files in a similiar way.
>
> buid.ksh:
> =======
> export SupportBase="F:/temp/OpenSG/supportlibs"
>
> export BoostBaseDir="$SupportBase/boost"
> export VtkBaseDir="$SupportBase/Vtk"
>
> export add_incdir="$SupportBase/support/inc"
> export
> add_libdir="$SupportBase/support/lib;$SupportBase/MemManager/libd"
> export add_lib="MemManagerD.lib"
>
> export collada_incdir="$SupportBase/support/inc/collada"
> export collada_libdir="$SupportBase/support/lib"
> export freetype_incdir="$SupportBase/support/inc/freetype"
> export freetype_libdir="$SupportBase/support/lib"
> export glut_incdir="$SupportBase/support/inc/GL"
> export glut_libdir="$SupportBase/support/lib"
> export zlib_incdir="$SupportBase/support/inc"
> export zlib_libdir="$SupportBase/support/lib"
> export xml2_incdir="$SupportBase/support/inc/libxml"
> export xml2_libdir="$SupportBase/support/lib"
> export tiff_incdir="$SupportBase/support/inc"
> export tiff_libdir="$SupportBase/support/lib"
> export png_incdir="$SupportBase/support/inc"
> export png_libdir="$SupportBase/support/lib"
> export jpeg_incdir="$SupportBase/support/inc"
> export jpeg_libdir="$SupportBase/support/lib"
>
> ./scons BoostBaseDir=$BoostBaseDir \
> VtkBaseDir=$VtkBaseDir \
> add_incdir=$add_incdir \
> add_libdir=$add_libdir \
> add_lib=$add_lib \
> collada_incdir=$collada_incdir \
> collada_libdir=$collada_libdir \
> freetype_incdir=$freetype_incdir \
> freetype_libdir=$freetype_libdir \
> glut_incdir=$glut_incdir \
> glut_libdir=$glut_libdir \
> zlib_incdir=$zlib_incdir \
> zlib_libdir=$zlib_libdir \
> xml2_incdir=$xml2_incdir \
> xml2_libdir=$xml2_libdir \
> tiff_incdir=$tiff_incdir \
> tiff_libdir=$tiff_libdir \
> png_incdir=$png_incdir \
> png_libdir=$png_libdir \
> jpeg_incdir=$jpeg_incdir \
> jpeg_libdir=$jpeg_libdir \
> enable_unittest=false \
> enable_gif=no \
> var_type=debug \
> var_arch=default \
> MSVS_VERSION=9.0
>
> # default_opt_level=maximum \
>
> As you can see I'm building with vtk and collada.
>
> In order to get vtk running changing file
> Tools\scons-build\OpenSG\AddOnHacks.py was necessary because my vtk file
>
> layout doesn't matches the expected file layout. This is unfortunate, I
> would like to see a possibility for customization at the command line.
> In
> particular it would be fine to discriminate the debug and release
> builds.
> Currently, I have to do this by hand in line 103.
>
> My vtk layout goes as follows:
> $SupportBase/vtk
> $SupportBase/vtk/inc
> $SupportBase/vtk/inc/vtkstd
> $SupportBase/vtk/lib/Debug
> $SupportBase/vtk/lib/Release
> $SupportBase/vtk/bin/Debug
> $SupportBase/vtk/bin/Release
>
> With collada currently I do have problems. With a former version
> (collada
> 1.4.1 dom 1.3.0, scons-local-0.96.95) I did not face any problems.
> Later, I
> will come back to my collada problems. But first I will describe what I
> have
> to do in order to get the rest running. On excluding the collada stuff
> it
> should be possible to build the OpenSG framework this way.
>
> 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').
> Next I'm building with the special memory manager. In order to use this
> I
> need to link to a special library (MemManager.lib, MemManagerD.lib) and
> to a
> special object file (NewDeleteImpl.obj, NewDeleteImplD.obj). I could add
> the
> linkage of the dll at the command line but I was unable to add the
> object
> from the command line. Therefore I was forced to change the file
> Tools\scons-addons\src\SConsAddons\EnvironmentBuilder.py (line 456 and
> 486,
> LINKFLAGS statements). 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...
> 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.
> 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.
> 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.
> 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 )
> 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.
> I do not know, if I always have found the best solution to the problems.
> I
> would appreciate if someone can provide better alternatives. However, I
> could go a long way with these. Please excuse this longish mail...
Thanks for sharing your experiences, I'll keep them in mind for when I
get back to working on the build.
Carsten
-------------------------------------------------------------------------
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
