Hi, On Thu, 2009-07-02 at 09:55 +0200, Marcus Lindblom wrote: > Gerrit Voß wrote: > > > ok, I did the changes, could you check if they make sense for you. > > Small warning of which you most likely are aware, you have to start > > with a blank/empty cache to get these changes pulled in correctly as > > the compiler settings are manipulated only once in the very beginning. > > > > I also updated the boost handling so the cmake file should respect > > Boost_USE_STATIC_LIBS as set. Another small warning I stumbled across, > > the std cmake boost find mechanism only react to these settings > > (static + mt) the very first time, once Boost has been found changing > > these flags/options does not change which boost libraries are used. > > So you have to delete/clean the cache to get changes in. > > Ok. Is there an easy way to warn the user of this? (I'm likely to forget t)
Hmm, have to think about it, but it should be possible. Do you want a warning or an error. I would tend to error. > > PDB file are generated for all targets but I made the install optional > > (OSG_INSTALL_PDB_FILES). I also added an option > > (OSG_USE_SEPARATE_LIBDIRS) so you can choose where the libs are placed > > during the install, the general lib dir or a target specific subdir. I > > still keep both .lib and .dll files in the lib dir, windows seems more > > to tend to install the .dll file in the bin dir. Would you prefer the > > bin dir or is the lib dir ok ? > > We don't use the install directly anyway, so either is fine with me. ok. > > If you have anything else let me know. One open issue is custom > > compiler flags. > > > > I'm also not sure all the 3rd party libs are handled correctly for > > all variants. I'll try to check this but it will take a second as > > windows builds are so slow ;( And I have to build the 3rd party > > lib variants ;( > > We/I need to reduce the #include-hogging for that. jep, but I still don't have a really good idea for that. We did the simple approach with scons but that confused the hell out of debuggers and me when I again edited the wrong file just to find it overridden after the next build ;( > I'll keep an eye open when it's time to compile. :) > > Note that for third-party libs, we don't really need all those variants > there. Just something built against debug/release runtimes. It's more a > matter when debugging against OpenSG itself that these additional > variants are useful. currently it only builds Debug/Release. Maybe we could switch Debug to DebugOpt, but at least once I had to debug 3rd party stuff (collada) because either collada itself or libxml2 was buggy, forgot the details already ;). kind regards, gerrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
