Gerrit Voss wrote:
Hi,
Carsten Neumann wrote:
Hello Thiago,
Thiago Bastos wrote:
I'm having a bit of a hard time trying to follow the
nomenclature/installation standards in effect on OpenSG 2.0 (revision 1684).
First, the install directory for libs differ on Windows and Linux. On
Linux the Release libs go to "lib", the Debug libs go to "lib/debug" and
the DebugRT libs go to "lib/debugrt". On Windows the libs go to
"lib/opt", "lib/dbg" and "lib/debugrt", respectively.
hm, yes this is a bit strange.
that was a quick hack just to avoid overriding the libs on Windows. I'm
fine with taking out the opt part in lib/opt. I guess it is a leftover.
I'm not sure if Linux really needs a debugrt version.
If they are all three ABI-compatible, it doesn't make much sense, no.
It would be preferable to have the libs
in the same dir with different suffixes, so we wouldn't need to update
any environment variable (PATH/LD_LIBRARY_PATH) to switch between the
Debug and Release version of our applications.
Hmmm I noticed that the DebugRT libs get a "_d" suffix, maybe we should
be using DebugRT instead of Debug?
perhaps; if you want something that works with the debug runtime.
As said before both variants have valid uses. I followed the naming
scheme that was usual for Windows, e.g. dll's that need the debug crt
get a d suffix in whatever form (the _d comes from scons and is not
my invention IIRC, 1.x uses plain D IIRC).
If it really bothers people we can make it an option to install
release and debugrt just to <prefix>/lib and keep the debug
variant in a separate subdir. Actually if it is really to confusing
I'm also fine to rename DebugRT to Debug and the old Debug to something
else, as long as we find a reasonable good name for it.
Cmake has something it calls RelWithDebugInfo, but I'm not sure if it's
optimized or not. ReleaseNoOpt would probably be the most accurate name.
(And debug-info should always be present, regardless of optimization, as
I've said a few times before... :)
Cmake keeps Release/Debug as they have been historically. There is also
a MinSizeRelease which takes ages to link (as this mode can not use
incremental linking) but strips the binaries of all duplicate code.
IIRC, this was what OpenSG 1.x used for Release, which is good for
generating a release, but hell when developing.
And why you really need it is that it also encodes the difference
between the 32 bit and 64 bit locations (e.g /usr/lib vs. /usr/lib64).
I have no clue what the preferred Windows way for adjusting install dirs
according to this difference is, actually I have no clue about preferred
Windows install dirs in general other that dumping anything somewhere
below 'C:\Program Files\<PackageName>' and if you are lucky and get
admin rights and start polluting C:\WINDOWS\System. So any suggestions
or references how to do it right are welcome.
I don't have that much insight into how that would work, as I've setup
up our own build/confugre system that tries to shield each developer
from what's actually installed on his/her system, and only use what
we've specified in the repository. I do a lot of
copying/linking/env-setup to make that happen, but it works pretty
nicely and allows you to develop simultaneously on revisions that use
different versions of third-party libs and apps. (I'm probably going to
open-source it, because it's quite nice, but a bit of an experiment at
the moment)
So as long as things are named suitably, I can setup env-vars and
directories that make things work.
You could always look at boost. They ship with installers. They are
converting to cmake as we speak. They can build a lot of variants and
have various suffixes to identify the important differences. And
Boostpro has installers. (Which put things under c:\program
files\boost\boost-xx.yy.zz and optionally adds the dll-dir to PATH.)
As far as I can guess, putting dll's into <prefix>/lib is wrong anyway
as only .lib files should go there and the dll's end up in <prefix>/bin.
I'm fine with mixing things, but other people might not be. The .pdb
files should also go into /bin, btw.
/Marcus
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
