Hi
On 4/24/07, Anders Backman <[EMAIL PROTECTED]> wrote:
Windows XP,
VisualStudio 8.
You are not alone, buddy, I'm on the same boat :)
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)
2. OpenSceneGraph still refers to the name OpenThreadswin32.lib
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;-) ?
Well, there is no good path *by default*. The only thing I am sure of is
that C:\Program Files is one of the worst place to put compiled libraries
and headers. Imagine what would happen if each library created a directory
in Program Files, it would be such a mess ... I mean, most of us are using
tons of libs, and not just OT/OSG.
For the past 3 or 4 years I've been using something very close to the
/usr/local UNIX paradigm for installed libs, and works quite well. I've
created a directory (call it c:\libs or whatever) where I install all the
libraries. I reference it using a system-wide USR_LOCAL environment
variable. %USR_LOCAL% contains 3 directories: include/, libs/ and bin/. The
%USR_LOCAL%\bin directory is added to the PATH, while the
$(USR_LOCAL)\include and $(USR_LOCAL)\lib are added to Visual Studio's
include and library paths, respectively. Altogether it means that installing
a library on the system boils down to copying the public headers in
%USR_LOCAL%/include, copying .lib and .exp files to %USR_LOCAL%/lib/ and
copying .dll and .pdb files to %USR_LOCAL%/bin/. This installation process
can be easily scripted (I used a python script before the OSG went to cmake
but I'd be glad to switch to the INSTALL part of the Visual Studio solution)
If the cmake build environment has to contain an installation procedure for
windows, I think it should really consider this alternative by default
rather than the Program Files route.
Now I don't know what other users from the community think, but I'd really
not appreciate that by default OSG expects to find OpenThreads (or any other
dependency) in c:\program files. Program Files is for ... programs, which
libraries are not. Plus using this kind of installation scheme will make the
LIBRARYNAMEHERE_DIR envars proliferate.
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.
Please don't :) I mean, why should you use different versions of a library
if it has ascending compatibility ? Just recompile your sources against the
latest. If it does not compile, fix your source. If you can't, just forget
about using the latest version and stick with an older one. Or append a
version number to the .lib and .dll files (and to the include dir) - this is
the UNIX way.
Debug and Release are different anyway (trailing d for Debug) so they can be
installed in the same place.
So what is the opinion of other windows users about path names?
That was my 2 cents. Windows and UNIX are so close, but common is the belief
that they are not. People often try to find different solutions for problems
that can be solved the same way.
Regards
Thibault
/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/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
