On Mon, 2011-10-24 at 14:53 +0100, James Turner wrote: > On 24 Oct 2011, at 13:17, Geoff McLane wrote: > > > > > In my case I like to be able to compile > > against different versions of say OSG - like - > > > > OSG301=1 # stable release 3.0.1 - default > > OSG283=0 # general release 283 - option > > OSG299=0 # another development release > > OSGTRUNK=0 # option, for 'trunk' version > > > > I have yet to try the idea from Mathius, using > > a semi-colon set of paths, maybe replacing some > > or all the 'export' items, like - > > -D "CMAKE_PREFIX_PATH=/path/to/osg;/path/to/simgear;..." > > - this seems a good idea to try... maybe cmake > > will like it ;=)) > > Okay, *but*, for your own sanity, you need to keep the Simgear-built-against > each of these separate too (anf FlightGear). By all means install each OSG > somewhere special, but then you need to build FG and SG against the same > version - so you may as well share a prefix for that build config (this is > what Jenkins does to build trunk OSG vs stable) > > Put it another way - you need to reconfigure and rebuild SG & FG entirely, > when switching OSG version, so I don't see any problem with installing to the > prefix for that OSG build too. > > I'd do: > mkdir osg-build-301 > cd osg-build-301 > cmake ../path/to/osg-301-source > -DCMAKE_INSTALL_PREFIX=/path/to/install/dist-osg-301 > make install > cd .. > mkdir sg-build-with-osg-301 > cd sg-build-with-osg-301 > cmake ../path/to/simgear > -DCMAKE_INSTALL_PREFIX=/path/to/install/dist-osg-301 > make install > cd .. > > ... and repeat once more for FlightGear > > > Mathias' suggestion also works, BTW - specify CMAKE_PREFIX_PATH, with one (or > several) paths to search - I tested that this morning and updated the README. > > As you guessed, manually setting the the detection variables > (SIMGEAR_VERSION_OK, etc) is a bad idea, unless you set *all* the generated > variables correctly - not impossible, but a lot of work. The error you report > looks like it's happening because the detection script has got confused, but > I need to see the arguments / environment passed to CMake, to understand why. > > James > Hi James,
As always thank you for your input... Yes, I hear you, and understand to use different versions of OSG, you need to redo both SG and FG at the same time... I do all of this using my 'makefg' script, so such a feat is as easy as pie ;=)) - .../fg16$ makefg OSG301 FGCLEAN SGCLEAN .../fg16$ mv install/fgfs install/fgfs-301 .../fg16$ mv run_fgfs.sh run_fgfs_301.sh .../fg16$ edit run_fgfs_301.sh to add '-301' .../fg16$ makefg OSG283 FGCLEAN SGCLEAN .../fg16$ mv install/fgfs install/fgfs-283 .../fg16$ mv run_fgfs.sh run_fgfs_283.sh .../fg16$ edit run_fgfs_283.sh to add '-283' .../fg16$ makefg OSG299 FGCLEAN SGCLEAN ...etc...etc... Then I can run the versions via the run_fgfs-ver scripts, side-by-side if desired... real simple... no problem... And all this noise is only about getting that script exactly 'right' to now use cmake, as it did previously with automake... and I am willing to take the time ;=)) > need to see the arguments / environment > passed to CMake, to understand why. But in each case I have explicitly given you the exact exports and cmake commands used... What more do you need? Anyway, as mentioned, have moved onto doing the same SG/FG/TG update in my XP WIN32, since there the powerful source view debugger will allow me to trace easily into say a tile load... But have already encountered a problem or 2 which you may be able to help with... I am sure I will be able to HELP enhance and maintain the cmake files as I gain more understanding... But the problems at the moment are that it 1. can NOT compile sgsound due to NOT finding <AL/al.h> The GUI asks for the OPENAL_LIBRARY, which in my case is - C:\Program Files\OpenAL 1.1 SDK\libs\Win32\OpenAL32.lib But for some reason it does NOT ask for an OPENAL_INCLUDE, which of course would be - C:\Program Files\OpenAL 1.1 SDK\include Like it does for multiple OSG, and JPEG, ZLIB, etc... And that additional path needs to be added to the additional paths when building this particular library, but it does not matter if it is added to ALL builds... Of course I can manually fix this in the MSVC IDE, *OR* I could COPY AL/al.h to the '3rdparty/include' I am using, that already contains many other of the 3rd party dependents... But the 'correct' fix would be for the CMake GUI ask where to find it... How can I do this? 2. It fails on linking test_binobj, Configuration Debug, with link error LNK2005: LIBCMT.lib conflicts with LIBCMTD.lib... But this does not make sense. It is building the Debug configuration, so why has it linked also with the NON-Debug version... AH HA! There it is - cmake is linking with all the correct Debug SG libraries, like sgiod.lib, note the added 'd', but makes a MISTAKE with C:\FG\30\3rdparty\lib\zlib.lib!!! That should be zlibd.lib... Again I can manually FIX the link, but that fix will be over-written next time I do a [Generate], so as always seek how to 'teach' cmake the rule... Of course CMAKE_DEBUG_POSTFIX=d - that's how it knew to use sgiod.lib, but why did it NOT apply this rule to zlib.lib??? In other cmake builds, indeed like that for OSG it only ever asks for one of libraries like zlib.lib, libjpeg.lib, libpng.lib, etc, etc, and seems to always 'know' that will be plus a 'd' for the Debug build... Why did it NOT apply that rule in this case? Is there something I can change in the CMakeLists.txt files to make this happen? 3. Question of library output directory This is NOT really a problem, but again wonder if cmake can be 'taught' to do it differently... Of course I have unchecked SIMGEAR_SHARED since the very LAST thing I want in Windows is to have ANOTHER big set of DLLS to look after... In fact my build of OSG was likewise just static, just so I can produce a fgfs.exe that will run anywhere, without having to cart around, or deal with, a big bunch of OSG DLLs... so I certainly do not want that for SG as well... In the CMake GUI I had chosen C:/FG/30/simgear/build as where to build the binaries... And use the CMAKE_DEBUG_POSTFIX of 'd', as mentioned... But at present it is outputting the libraries to C:/FG/30/simgear/build/simgear/io/debug/sgiod.lib and C:/FG/30/simgear/build/simgear/io/release/sgio.lib Ideally I would 'like' it to output them all to C:/FG/30/3rdparty/lib/sgiod.lib and C:/FG/30/3rdparty/lib/sgio.lib That is the whole purpose of using this 'd' for the Debug, to keep the names separate... thus do NOT want them placed in .../build/<projects>/<debug|release>/<lib>[d] So again, do you know of a way to 'teach' cmake this little trick ;=)) Again, of course I can do a manual copy later... As you can see this is all SG, but will shortly move on to FG, and then TG... Hope you can help... Regards, Geoff. ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
