Hello Jean-Sébastien,
megamillerzoid wrote:
the versioning is not the problem, but libs also get a prefix. This way
their final location will be in
the bin folder.
Jean-Sébastien Guay wrote:
Libs should go in lib/, and DLLs and executables should go in bin/ ...
I understand, I called
Jean-Sébastien Guay wrote:
adapting the build files generated for nmake to make it accept the versioned
DLLs
Nope, I adapted the cmake files so it generates correct build files for nmake.
The changes had to be done at many places in (OsgMacroUtils and two
CmakeLists.txt) (libs, linking, apps,
Hartmut Seichter wrote:
If you tried the newest trunk and SWIG you certainly stumbled across the
osg::Vec3f stuff ... do you have a solution for that?
I don't know what stuff ypu mean, I have just tested the latest svn-trunk (osg
2.3.4) with swigwin-1.3.29 without problems.
So maybe using an
Dear OSG-Users,
I am using commandline build system nmake on windows,
since the OSG_MSVC_VERSIONED_DLL hack this does not work anymore,
because there are hard-coded paths to move the dll's, but nmake has different
locations for the files.
There are two solutions,
1: change IF(MSVC) on line
I have worked with the swigged version of osgPython for some time.
It works pretty well, I updated the online version (to osg22)
and added python style vectors, cmake system and some other extra's
It is part of a bigger library, maybe I can seperate it, and share it.
It uses the swig system of
Dear osgPython users,
About the problem with vectors,
There is a file in our library, called osgPyExtend, which creates python access
to vectors and mat.
I have attached it.
add %include osgPyExtend.i to osg.i
I have more additions, but this one should be an easy to add.
6 matches
Mail list logo
