Hi, On Thu, 2009-07-02 at 12:04 +0200, Johannes Brunen wrote: > Hello Gerrit, > > "Gerrit Voß" <vossg-pKHMZwtRCR/[email protected]> schrieb im > Newsbeitrag news:[email protected]... > > > > I guess it will be very similar. One possible difference I can see is > > that I directly include the OpenSG internal cmake helper, especially > the > > compiler setup parts so that the settings are as identical as they > > can be. And it will be an all in one setup, e.g. all the libs will > > be part of a single cmake setup and as a result a single vs solution. > > Oh, and both dll and static variants will be available (were > possible). > > > I'm just a beginner in the cmake land. Therefore my solution might not > be as > fancy. Just take a look...
Well I also only started quite recently. And looking at them they are quite similar, especially as both were at least inspired by the same source (vtk, if I'm not totally mistaken) > > > > And I will only include the things OpenSG needs directly: > > > > zlib, png, jpeg, tiff, freeglut, > > JasPer ,ilmbase ,OpenEXR, gdal, collada, libxml2 > > > I do have also to support some other stuff... > > But I did not manage to build gdal with cmake. See me impressed... I'm not there yet ;) So lets wait and see if I succeed or fail before being anything ;) > > > > For VTK I might go for an initial cmake cache. > > > Vtk's build cmake file is just fine. The most of work is on the > configuration side. I only use the vtk support libs which I do not build > > myself. And I do currently build only the vtk's debug and release > targets. > Additionally, I added the following statements to the vtk cmake script: > > add_definitions( > -D_CRT_SECURE_NO_DEPRECATE > -D_CRT_SECURE_NO_WARNINGS > -D_CRT_NONSTDC_NO_DEPRECATE > -D_SECURE_SCL=0 > -D_SCL_SECURE_NO_WARNINGS > -D_SCL_SECURE_NO_DEPRECATE > ) > > set(CMAKE_DEBUG_POSTFIX "D") > > However, in the near future, I will also set these via the command line > of > my build script. The same does hold for all other cmake projects I have > written. > > > > > Boost I will also leave untouched. For 32 bits there are good > prebuilds > > available, for 64bit I will just provide the command line. > > > As I do use the -D_SCL_... settings I have to build the boost libraries > myself as it produces an new ABI configuration. yes I figured that one out yesterday while playing with the /MD /D_DEBUG settings ;( I still can't believe somebody would do things where you silently break binary layout between libs without at least the possibility to detect it. > However, I do not build > the > boost libraries with my script on a regular basis. Just to expensive in > the > time space. Understandable ;) > As a side note, I did patch the bjam msvc.jam file in order > to > implement a 'stl-security-theater' variant. I saw somewhere else people use/suggested to add 'define=_SCL... define=_SCL... define=...' to the bjam call. So before I try this was there a reason to modify the jam file instead of using the arguments ? > There was some discussion > about > that on the boost developer mailing list. > > I use the following bjam build statements (just for your info...): > bjam.exe --stagedir=./stage32 toolset=msvc-9.0 variant=debug,release > threading=multi link=shared,static runtime-link=shared address-model=32 > stl-security-theater=off stage > bjam.exe --stagedir=./stage64 toolset=msvc-9.0 variant=debug,release > threading=multi link=shared,static runtime-link=shared address-model=64 > stl-security-theater=off stage is the stl-security-theater=off option coming from the change you did to msvc.jam or is it something there already ? > > > > The one thing I'm not sure about is if I should mangle exported names > > like VTK does or not. Currently the lib name carries an osg tag. > > > I guess this is necessary. Otherwise the user is forced to syncronize > all > the libraries of a particular type (say zlib) which he uses. Actually, 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. > 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 ? Later I will make the osg part an option. > > > > I guess the best way forward might be if you could send a small > > sample cmake setup, e.g. for png or tiff so we can see how we can > > find a joint solution. I plan to have an initial subset available > > later today so everybody can have a look ;) > > > Yes, here it goes... thanks kind regards, gerrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
