Re: [osg-users] DLL versioned MSVC and NMAKE problem, relative paths are wrong
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 the dll's libs... in cmake ${LIB_NAME} is used, and the
${LIB_NAME} target (among others) gets the wrong prefix property. In my fix the
.lib files will go in the lib dir (without a version prefix), just like in
Visual Studio Solutions.
If it is possible to use Visual Studio Express Edition and command line build,
let me know, as far as I know the command line files are not in the express
edition.
I also use nmake, because it triggers cmake before building, if this happens in
visual studio you will have to reopen all you projects (the project has been
changed from outside...). This makes testing cmake scripts more time consuming.
(if someone knows how to avoid closing/opening visual studio or reloading the
projects one by one let me know).
Jean-Sébastien Guay wrote:
Though it seems you are the only one using nmake to build OSG
:-)
I have used this build system with osg for over two years now, it worked
perfectly until the current cmake hack (adding../../bin to move files) was
created. I think a better (cmake) solution is possible.
Thanks for your feedback!
I will take a look at the submission mailing list.
René
_
Bekijk Yes-R's real life soap op MSN Video!
http://video.msn.com/video.aspx?mkt=nl-nltab=m1192527562294vid=8aff5b76-b78d-4b55-8b64-ef7e1d73aab2playlist=videoByUuids:uuids:50b732c2-c105-41e9-adf0-36bd627d4eaa,0813da8c-031b-423f-a79d-35d925aee805,5cce447e-948d-43af-9862-45bb6bb9d6d8,6a39138c-f562-4254-be70-9d93343650f8,f9b8d78f-05a4-4c74-8e4b-28d20a4037abfrom=NLNL_Yes-R
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DLL versioned MSVC and NMAKE problem, relative paths are wrong
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, plugins. wrappers)
The problem with the hard-coded paths to move the dll's is this:
Visual Studio creates Release and Debug folders,
the versioning is not the problem, but libs also get a prefix. This way their
final location will be in the bin folder.
For example (for the plugins):
PREFIX = ../../bin/${OSG_PLUGINS} which will become something like
../../../lib/release/../../bin/osg/osgPlugins-2.2.0/
if you generate files for nmake this 'trick' will not work, it has to be:
../bin/${OSG_PLUGINS}
I have created a fix for this...
Let me know if this needs to be submitted.
Rene
_
De mooiste afbeeldingen van Angelina Jolie vind je met Live Search
http://search.live.com/images/results.aspx?q=angelina%20jolieFORM=MIINTM
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg python binding
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 older swig version is a workaround for now.
I noticed one swig error before, that was solved like this:
//This is a little macro trick to prevent a swig error
#define X_AXIS(a,b,c) X_AXIS=Vec3f(1.0,0.0,0.0);
#define Y_AXIS(a,b,c) Y_AXIS=Vec3f(0.0,1.0,0.0);
#define Z_AXIS(a,b,c) Z_AXIS=Vec3f(0.0,0.0,1.0);
and this might be handy
//create shortcuts for vecs in python
#ifdef SWIGPYTHON
%pythoncode %{
Vec2 = Vec2f
Vec3 = Vec3f
Vec4 = Vec4f
%}
#endif
We changed some other stuff too, but the result in python is this:
In [1]: import osg
In [2]: a = osg.Vec3(1,2,3)
In [3]: a
Out[3]:
In [4]: print a
[1, 2, 3]
In [5]: myvec = osg.Vec3f()
In [6]: myvec[0] = 10
In [7]: print myvec
[10, 0, 0]
When I find some time, I will try to see what the differences between our
trunks are. And I will look at our cmake files.
Have a nice day,
René Molenaar
_
Probeer Live Search: de zoekmachine van de makers van MSN!
http://www.live.com/?searchOnly=true
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] DLL versioned MSVC and NMAKE problem, relative paths are wrong
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 142, 158, 299 and 301 of CMakeList.txt (r7885) to IF(MSVC_IDE) This fixes the problem, but the dll's are now not versioned and in the /lib dir 2: change the macro's in OsgMacroUtils.cmake for the IF(NOT MSVC_IDE) situation. Not sure what needs to be changed, but that way we can keep the versioning and /bin placements I was wondering if this change should be in the repository, if so please instruct me to summit the changes, (i'am still experimenting with the solution 2 suggestions are welcome). I am also trying to build on other platforms (linux, sun, aix, hp) not without problems, where can I sent an overview of my feedback? Have a nice day, René Molenaar _ De mooiste afbeeldingen van Angelina Jolie vind je met Live Search http://search.live.com/images/results.aspx?q=angelina%20jolieFORM=MIINTM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg python binding
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 cmake and works on both windows and linux. As far as I know the swig osgPython is the best solution at this moment for osgPython. René Molenaar _ Bekijk Yes-R's real life soap op MSN Video! http://video.msn.com/video.aspx?mkt=nl-nltab=m1192527562294vid=8aff5b76-b78d-4b55-8b64-ef7e1d73aab2playlist=videoByUuids:uuids:50b732c2-c105-41e9-adf0-36bd627d4eaa,0813da8c-031b-423f-a79d-35d925aee805,5cce447e-948d-43af-9862-45bb6bb9d6d8,6a39138c-f562-4254-be70-9d93343650f8,f9b8d78f-05a4-4c74-8e4b-28d20a4037abfrom=NLNL_Yes-R ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg python binding
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.
_
Jouw nieuws en entertainment, vind je op MSN.nl!
http://nl.msn.com/ %{
#include sstream
%}
%define VECHELPER(name)
value_type __getitem__(int i) { return (*self)[i]; }
void __setitem__(int i, value_type v) { (*self)[i] = v; }
%enddef
%define VEC2HELPER(name)
%extend osg::## name
{
std::string __str__()
{
std::ostringstream os;
os '[' self-x() , self-y() ']';
return os.str();
}
VECHELPER(name)
};
%enddef
%define VEC3HELPER(name)
%extend osg::## name
{
std::string __str__()
{
std::ostringstream os;
os '[' self-x() , self-y() , self-z() ']';
return os.str();
}
VECHELPER(name)
};
%enddef
%define VEC4HELPER(name)
%extend osg::## name
{
std::string __str__()
{
std::ostringstream os;
os '[' self-r() , self-g() , self-b() ,
self-a() ']';
return os.str();
}
VECHELPER(name)
};
%enddef
%define MATHELPER(name)
%extend osg::## name
{
std::string __str__()
{
std::ostringstream os;
os '[' self-operator()(0,0) , self-operator()(0,1)
, self-operator()(0,2) , self-operator()(0,3) ']';
os '[' self-operator()(1,0) , self-operator()(1,1)
, self-operator()(1,2) , self-operator()(1,3) ']';
os '[' self-operator()(2,0) , self-operator()(2,1)
, self-operator()(2,2) , self-operator()(2,3) ']';
os '[' self-operator()(3,0) , self-operator()(3,1)
, self-operator()(3,2) , self-operator()(3,3) ']';
return os.str();
}
};
%enddef
VEC2HELPER(Vec2b)
VEC2HELPER(Vec2s)
VEC2HELPER(Vec2d)
VEC2HELPER(Vec2f)
VEC3HELPER(Vec3b)
VEC3HELPER(Vec3s)
VEC3HELPER(Vec3d)
VEC3HELPER(Vec3f)
VEC4HELPER(Vec4ub)
VEC4HELPER(Vec4b)
VEC4HELPER(Vec4s)
VEC4HELPER(Vec4d)
VEC4HELPER(Vec4f)
MATHELPER(Matrixd)
MATHELPER(Matrixf)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
