Hi, On Fri, 2009-07-03 at 09:13 +0200, Johannes Brunen wrote: > Hi Gerrit, > > "Gerrit Voß" <vossg-pKHMZwtRCR/[email protected]> schrieb im > Newsbeitrag > news:<[email protected]>... >
> > > > I'm not there yet ;) So lets wait and see if I succeed or fail before > > being anything ;) > > > After rethinking about the libs I can say that the openexr lib did hurt > the most. I can imaging. I tried to build EXR once but gave up IIRC ;) > > > > is the stl-security-theater=off option coming from the change you did > to > > msvc.jam or is it something there already ? > > > No I did patch the msvc.jam file myself. The patch goes actually back to > Mat Marcus: > > http://article.gmane.org/gmane.comp.lib.boost.build/17824/match=high+cos > t > > He did come up first with performance problems introduced by the new > default settings of the microsoft vc8 platform. There was some > discussion on the boost list and I did hoped that something along the > patch would be become part of the boost build system. This did not > happen until today (hope I didn't miss it, however). Actually, I could > use the command line variant, but I stick to approved procedures. > > The patch is quite simple and looks like this (sorry no standardise > patch syntax, which I didn't masterd until now): > > patched: > D:\Libs\boost_1_39_0\tools\build\v2\tools\msvc.jam > # Declare msvc toolset specific features. > { > feature.feature debug-store : object database : propagated ; > feature.feature pch-source : : dependency free > ; > + feature.feature stl-security-theater : off on : propagated > link-incompatible ; > } > > + toolset.flags msvc.compile C++FLAGS <stl-security-theater>off : > /D_SECURE_SCL=0 /D_SCL_SECURE_NO_WARNINGS /D_CRT_SECURE_NO_DEPRECATE > /D_SCL_SECURE_NO_DEPRECATE ; > + toolset.flags msvc.compile C++FLAGS <stl-security-theater>on : > /D_SECURE_SCL=1 /D_SCL_SECURE_NO_WARNINGS /D_CRT_SECURE_NO_DEPRECATE > /D_SCL_SECURE_NO_DEPRECATE ; ok. > > yes, that is what I'm worried about. The good thing is the security > > stuff only affects C++ so a lot of the more common small helper > > C libs (like zlib) have less variants to deal with. > Yes. > > >> I'm on that track... > > to mangle the lib name, for example use osgzlib instead of zlib or > > to fully mangle the exported function names ? > No my track is to force all libraries part of my application, to use the > very same support components. ok. > I have build the OpenSG (not the support) libraries yesterday. All of > the libraries build fine but the installation procedure did not work as > expected. I have seen a regression to the former behavior. First, I have > attached the CMakeCache.txt file, so you can look up the exact settings > I did use. The effect I have is that only the OSGBaseXXX.lib and > OSGBaseXXX.dll files got installed in the corresponding lib folders. > The header folder is completely missing from the include installation > path. hmm, fascinating I'll have a look. I thought I tested it but it might be that I screwed something in between. > I did use the following settings: > > OSG_INSTALL_PDB_FILES:BOOL=ON > OSG_USE_OSGSUPPORT_LIBS:BOOL=OFF > OSG_USE_SEPARATE_LIBDIRS:BOOL=ON > OSG_USE_STATIC_SUPPORT_LIBS:BOOL=OFF > > Later on today, I will have a finer look of what went wrong with the > setup. > > > As I saw, you introduced cmake variables variants (debug and release) > for the support libraries. However, you only use them with the > > OSG_USE_OSGSUPPORT_LIBS:BOOL=ON > > setting. It would be fine if we can use these variables also for > > OSG_USE_OSGSUPPORT_LIBS:BOOL=OFF > > in case the user provide sensible input for them. I have to see if there is an easy way to do this because IIRC the rest of cmake is not very aware of all the windows variants. And IIRC the more common LIB_VAR=debug;/libD.lib;optimized;lib.lib way of finding packages does not work with custom variants (which is a real pain). For your case it might be easier we either agree on naming the libs or I make naming them flexible enough so you can slip in your builds as OpenSG Support libs and utilize this. Currently it just looks for a specific header under ${SUPPORT_ROOT}/include and the libs under ${SUPPORT_ROOT}/lib. As long as your names match it should not be a problem. The only assumption I make is that glut is actually freeglut when it comes through there. > > One last point. I would prefere if the OpenSG libs could be installed in > a subfolder OpenSG of the destination lib folder. This way it is a > little simpler to sort things out in case of bigger libs. > ok, I'll add this option along with the bin dll install which is still on my list. kind regards, gerrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
