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.
>> Second, I think it's a bit problematic to have both the Release and
>> Debug libs with the same name.
>
> as long as they can be used interchangeably, I disagree. A program
> should not care whether it is using a shared lib with debug symbols in
> it or not.
> Hm, now that I think about it I'm not sure if we are careful enough with
> the use of the OSG_DEBUG define here, perhaps we need to split this into
> OSG_DEBUG and OSG_DEBUGRT where the former may not break ABI compatibility.
at least one location I changed to take care of this difference (share
object name generation). Don't know if I missed something somewhere.
>> 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.
>> Finally, with this platform disparity, the distributed
>> "FindOpenSG.cmake" only works on Linux.
>>
>> So, is it in your plans to standardize lib locations throughout
>> platforms (or at least fix FindOpenSG.cmake)?
>>
>> PS: do you have plans to add support for "make package"? It's quite easy
>> if "make install" is already working.
>
> hm, what does it do and how do I make it work? ISTR you know cmake quite
> well, would you consider sending a patch?
>
>> PS2: I also think it's wierd that ${OSG_LIBDIR_SUFFIX} affects the lib
>> install dir only on Linux and not on Windows. This part of the code
>> seems a bit messy in the CMake files.
>
> yeah, could use a little love ;)
>
be careful, this is at least partially intentionally as for Windows you
have to be careful not to do settings depending on the CMAKE_BUILD_TYPE
because otherwise you get the wrong setup in Visual Studio as it is
configured to build all variants in parallel whereas the Makefile (e.g.
Linux) versions only build 1 variant per build dir and are less
sensitive to this problem.
So the preferred solution would be to remove OSG_LIBDIR_SUFFIX from
Linux and just specify the target directory explicitly.
On the other hand if different makefile based platforms require
different suffixes it is easier to keep OSG_LIBDIR_SUFFIX and
just change it in one location instead of crawling through all
the statements that might need change. You have to keep in
mind that the 'IF(NOT WIN32)' part is not a single other target but
anything from Linux over Solaris to OS X. So it might need more and
different variations than the single Windows thing. I guess there
might be some changes ahead anyway as sooner or later people will asked
to support Unix based IDE's other than emacs and I would expect we will
need to take the same precautions as for Visual Studio.
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.
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.
kind regards,
gerrit
------------------------------------------------------------------------------
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
