Anders Backman wrote:
What if you want to replace OpenThreads temporarily for a "patched" one?
What if you decide that you want to build with or without debug
symbols in the release library? Copying libs in windows is not a good
way to handle these things. Together with .lib/.dll there are pdb etc
for debugging, copying them back and forth is not very effective.
I rather prefer the unix style suggested by Thibault, we are using
something similar, where we make use of the LIB and INCLUDE
environment variable that exists for visualstudio.
By running a bat-file we set the LIB, INCLUDE and PATH variables to
whatever release/library/combination we want, then we start
visualstudio with devenv /useenv.
what is devenv/useenv ?
My rule is, NEVER store explicit paths in the .vcproj file, it always
fails when using multiple versions of libraries.
I realize this is not the way Cmake wants it, it rather want to get
all the paths, create hard-coded project files with all paths in it,
and then keep it like that.
I did not tested much, but you can probably set
CMAKE_USE_RELATIVE_PATHS to ask for projects that have not full path names.
Although there is nothing that prevents the user from starting
visualstudio with devenv /useenv anyway to make use of LIB/INCLUDE
env. variables, so I dont see any problems in that.
The only problem right now is that you have to INSTALL before using
OT, OSG and osgProducer.
That is something that is not strictly required by CMake, but is the way
it is now because we separate the builds.
I was used to build with CMake a whole project that included OT, OSG and
osgProducer, and was able to use it WITHOUT doing any installation step.
Would you prefer this kind of usage?
What would happen if you specify OpenSceneGraph as install path for
binaries/libs? Would it also try to copy header files?
The install step does exacly like that, it install also headers.
Copying header files is even more stupid, as the dates are changed and
sometimes you get a major recompile due to that.
But if the default installation lib (at least for windows) would be
the source directory then I think it would work just fine (as before),
and if someone (hope not) want to install code into Program Files or
Windows directory then its up to them.
CMake preferred setup is to build outside source, in order to avoid
touching source dir at all,
so making the default install prefix concide with the source dir seems
strange, but is probably doable.
If you install in source, headers are required to be installed in the
same place where they actually are.
Is CMake clever enough to notice it and do nothing?, furthermore you
will be using directly the headers from svn, so if you update
OpenThreads but you do not build the install target,
the you will probably be using new headers with old libs in subsequent
OSG builds.
/anders
On 4/24/07, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:
I had similar problem but noticed that one may set the same path as
Source
code, Binary root and Install path. In this case install just moves
release
and debug libs to lib subdirectory of the project and dlls and
executables
into bin subdirectory of the project. It does not copy Include dirs
because
they would land in the same dir.
For example:
I keep my all my OSG related projects in C:\dev\OSG_SVN directory.
So I use
C:\dev\OSG_SVN\OpenSceneGraph
directory for all three directory locations
for
source code directory ( "Where is the source code" in Windows Cmake )
for
binary directory ("Where to build the binaries" in Windows Cmake)
and for
install directory( CMAKE_INSTALL_PREFIX variable in Windows Cmake)
this produces similar results as defaul locations in older OSG
distributions
with this exception of Win32 subdir removed from lib and bin.
Cheers,
Wojtek Lewandowski
----- Original Message -----
From: "Anders Backman" <[EMAIL PROTECTED]>
To: "osg users" <[email protected]>
Sent: Tuesday, April 24, 2007 10:53 AM
Subject: [osg-users] OpenThread library name
> Windows XP,
> VisualStudio 8.
>
> I just checked out svn osg and OT and got some problems during build.
>
> I'm using a separate checked out version of OT, so I'm using the
> OPENTHREADS_DIR env variable to specify the path to OT.
>
> 1. It seems that OT generates OpenThreads(d).lib (and not
> OpenThreadswin32(d).lib as before)
It was a decided to use the same name across platforms
>
> 2. OpenSceneGraph still refers to the name OpenThreadswin32.lib
it should search for both OpenThreads and OpenThreadswin32, with a
preference to OpenThreads
>
> 3. In windows there is no really good path where to install headers
and
> libs.
> Is the new convention to install it to c:\program files\OpenTHreads
> something that the community has decided or is it a proposal to a new
> standard;-) ?
>
> It now also seems that one HAS to install OpenThreads to get the
> correct include/lib path for cmake. Otherwise the library resides
> under debug or minsizrel or release.
> This makes it slightly harder to use multiple versions of the library,
> as one has to install all of them to some common path.
>
> So what is the opinion of other windows users about path names?
>
> /Anders
>
> --
>
>
> ________________________________________________________________
> Anders Backman Email: [EMAIL PROTECTED]
> HPC2N/VRlab Phone: +46 (0)90-786 9936
> Umea university Cellular: +46 (0)70-392 64 67
> S-901 87 UMEA SWEDEN Fax: +46 90-786 6126
> http://www.cs.umu.se/~andersb
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
> -------------------------------------------------------------
> This mail was scanned by BitDefender
> For more informations please visit http://www.bitdefender.com
>
>
> -------------------------------------------------------------
>
>
-------------------------------------------------------------
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com
-------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
