Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 26 Oct 2011, at 19:24, Geoff McLane wrote: Maybe, as you have suggested, this is over kill, setting BOTH SIMGEAR_DIR in the environment, AND passing SIMGEAR_INCLUDE_DIR to cmake, and when I feel comfortable, I will eliminate one or the other for further testing... BUT now I have reached another wall... fgjs will not link ;=(( I think all these problems are related. I would suggest: - use CMAKE_PREFIX_PATH to get FindSimGear working. - don't set SIMGEAR_DIR, at all - it's simply not required once the prefix is set - don't set the variables which FindSimGear is supposed to set (VERSION_OK, etc), because you're only setting *some* of them, and hence your linker error in fgjs. Referring to your script, I'd make the following changes: - the ':PATH' here looks suspicious to me FGCM_OPTS=$FGCM_OPTS -D LIB_POSTFIX= -D CMAKE_INSTALL_PREFIX:PATH=$INSTALL_DIR_FGFS I think it only needs -D CMAKE_INSTALL_PREFIX=$INSTALL_DIR_FGFS - omit the 'ADDSGVOK' and 'ADDSGDIRS' pieces, which are defeating the FindSimGear module, and hence breaking your link commands - omit the OSG_DIR / SIMGEAR_DIR setting completely - set prefix path roughly like this: FGCM_OPTS=$FGCM_OPTS -DCMAKE_PREFIX_PATH=$INSTALL_DIR_SIMGEAR;$INSTALL_DIR_OSG Depending on what level of quote escaping is going on, you might need to quote that argument, but I'm not enough of a shell guru to be sure. You need the embedded semi-colon to be passed to cmake, though, not interpreted by bash. Hope this helps! James -- 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
[Flightgear-devel] New FlightGear Terrain Data
I have just uploaded 15 square degrees of land cover data to my website. These is the raw shapefiles needed to run TerraGear - they're ready to go to create scenery. THIS IS NOT FINISHED SCENERY. However after generating shapefiles for Lake Tahoe/Reno I realized that this scenery touched the northeast corner of the default San Francisco scenery. As a result I generated another 2x2 degree batch directly north of the default scenery, and directly west of Reno/Lake Tahoe. Should I go ahead and generate 30m land cover data to replace or augment the KSFO data? I am thinking, since this data is compatible with the FlightGear license, it may be possible once this scenery is generated to give users who are downloading the program for the first time a choice between the current 2 degrees around KSFO scenery, or up to 16 square degrees of detailed scenery around KSFO (and including Sacramento, Reno, Fresno, and Monterey). Their choice would be dependent on their graphics card and download speed. == The shapefiles I have generated are downloadable here. Please only download these files if you are interested in the raw shapefiles or if you wish to use the shapefiles as a base to run TerraGear: Minneapolis/St. Paul: http://www.stattosoftware.com/flightgear/w094n44.zip Durango/Telluride, Colorado: http://www.stattosoftware.com/flightgear/w109n37.zip Reno/Lake Tahoe: http://www.stattosoftware.com/flightgear/w121n38.zip Sacramento/Santa Rosa: http://www.stattosoftware.com/flightgear/w123n38.zip Cheers John -- 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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Fri, 2011-10-28 at 08:57 +0100, James Turner wrote: On 26 Oct 2011, at 19:24, Geoff McLane wrote: Maybe, as you have suggested, this is over kill, setting BOTH SIMGEAR_DIR in the environment, AND passing SIMGEAR_INCLUDE_DIR to cmake, and when I feel comfortable, I will eliminate one or the other for further testing... BUT now I have reached another wall... fgjs will not link ;=(( I think all these problems are related. I would suggest: - use CMAKE_PREFIX_PATH to get FindSimGear working. - don't set SIMGEAR_DIR, at all - it's simply not required once the prefix is set - don't set the variables which FindSimGear is supposed to set (VERSION_OK, etc), because you're only setting *some* of them, and hence your linker error in fgjs. Referring to your script, I'd make the following changes: - the ':PATH' here looks suspicious to me FGCM_OPTS=$FGCM_OPTS -D LIB_POSTFIX= -D CMAKE_INSTALL_PREFIX:PATH=$INSTALL_DIR_FGFS I think it only needs -D CMAKE_INSTALL_PREFIX=$INSTALL_DIR_FGFS - omit the 'ADDSGVOK' and 'ADDSGDIRS' pieces, which are defeating the FindSimGear module, and hence breaking your link commands - omit the OSG_DIR / SIMGEAR_DIR setting completely - set prefix path roughly like this: FGCM_OPTS=$FGCM_OPTS -DCMAKE_PREFIX_PATH=$INSTALL_DIR_SIMGEAR;$INSTALL_DIR_OSG Depending on what level of quote escaping is going on, you might need to quote that argument, but I'm not enough of a shell guru to be sure. You need the embedded semi-colon to be passed to cmake, though, not interpreted by bash. Hope this helps! James Hi James, Re: In Ubuntu linux, using script = Well yes, and no ;=)) Adding 2 paths, SG and OSG to CMAKE_PREFIX_PATH FAILED to find the OSG libraries, but as you point out maybe I got something wrong with the escaped quotes... But what did work was a separation into 2 :- (a) export OSG_PATH=$INSTALL_DIR_OSG (b) FGCM_OPTS=$FGCM_OPTS -DCMAKE_PREFIX_PATH=$INSTALL_DIR_SIMGEAR The full compile link completed, and I was flying in under 15 mins... Just for good measure I also did a fresh clone, and it too compiled fine... The updated script has replaced the previous at - http://geoffair.org/tmp/makefg And when I have time will go back and try to also tidy up, and simplify the SimGear build... Re: In Windows (XP WIN32) - using CMake GUI = Unfortunately, here not so good ;=(( for building FG. SG was not too bad... As mentioned, I had to add two options, PTW32_STATIC_LIB, to use pthreads (for Win32) static, and OSG_LIBRARY_STATIC, to use all static OSG libraries... After lots and lots of fiddling, changing things in the GUI, this way, then that way, was ONLY able to get a set of MSVC build files generated was by 'cheating', and adding SIMGEAR_VERSION_OK=TRUE I 'know' this is NOT GOOD, but without it could NOT convince CMake to even generate files... AND, perhaps as a consequence, of course the MSVC build files were very incomplete, in that, for the FlightGear build NO OSG nor SG libraries had been added for the link... And in fact there is no way to even give the various plug-in (static) libraries at all, but that is another issue... However, after manually 'fixing' each of the build files, I did manage to get it all linked ;=() But of course those 'fixed' build files are over written each time you run the GUI and do a new generation... And do not yet quite understand why each core SimGear library is the subject of three variables, like say SIMGEAR_BUCKET_LIBRARY SIMGEAR_BUCKET_LIBRARY_RELEASE SIMGEAR_BUCKET_LIBRARY_DEBUG Yes, in Windows we do need a Release and a Debug, separated, but what is this 1st item? Taking a clue from say the PLIB libraries, it seems this 1st should be filled in, in the form - PLIB_UL_LIBRARY = optimized;path/to/rel;debug;path/to/dbg PLIB_UL_LIBRARY_DEBUG = path/to/dbg PLIB_UL_LIBRARY_RELEASE = path/to/rel Presently for SG items have only filled in the Rel and Dbg items, which is already a BIG effort, but will try also filling it in like the PLIB items, since I recently found that one can manually 'fix' the build\CMakeCache.txt file... So this can be done faster in a good editor, than trying to fiddle in the GUI... Maybe when I do ALL this configuring things will work out better, and I can remove the SIMGEAR_VERSION_OK=TRUE ;=)) Anyway presently quite exhausted from this Windows effort ;=() At present it seems we are asking the Windows user to do a tremendous amount of configuration work BEFORE they can get into building... As always, appreciate any thought on this windows side of things... maybe I am doing something real wrong ;=() Regards, Geoff. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly.
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Geoff I hope James listens to you, I have been studiously ignored. Alan -Original Message- From: Geoff McLane Sent: Friday, October 28, 2011 7:20 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd) Re: In Windows (XP WIN32) - using CMake GUI = Unfortunately, here not so good ;=(( for building FG. SG was not too bad... As mentioned, I had to add two options, PTW32_STATIC_LIB, to use pthreads (for Win32) static, and OSG_LIBRARY_STATIC, to use all static OSG libraries... After lots and lots of fiddling, changing things in the GUI, this way, then that way, was ONLY able to get a set of MSVC build files generated was by 'cheating', and adding SIMGEAR_VERSION_OK=TRUE I 'know' this is NOT GOOD, but without it could NOT convince CMake to even generate files... AND, perhaps as a consequence, of course the MSVC build files were very incomplete, in that, for the FlightGear build NO OSG nor SG libraries had been added for the link... And in fact there is no way to even give the various plug-in (static) libraries at all, but that is another issue... However, after manually 'fixing' each of the build files, I did manage to get it all linked ;=() But of course those 'fixed' build files are over written each time you run the GUI and do a new generation... And do not yet quite understand why each core SimGear library is the subject of three variables, like say SIMGEAR_BUCKET_LIBRARY SIMGEAR_BUCKET_LIBRARY_RELEASE SIMGEAR_BUCKET_LIBRARY_DEBUG Yes, in Windows we do need a Release and a Debug, separated, but what is this 1st item? Taking a clue from say the PLIB libraries, it seems this 1st should be filled in, in the form - PLIB_UL_LIBRARY = optimized;path/to/rel;debug;path/to/dbg PLIB_UL_LIBRARY_DEBUG = path/to/dbg PLIB_UL_LIBRARY_RELEASE = path/to/rel Presently for SG items have only filled in the Rel and Dbg items, which is already a BIG effort, but will try also filling it in like the PLIB items, since I recently found that one can manually 'fix' the build\CMakeCache.txt file... So this can be done faster in a good editor, than trying to fiddle in the GUI... Maybe when I do ALL this configuring things will work out better, and I can remove the SIMGEAR_VERSION_OK=TRUE ;=)) Anyway presently quite exhausted from this Windows effort ;=() At present it seems we are asking the Windows user to do a tremendous amount of configuration work BEFORE they can get into building... As always, appreciate any thought on this windows side of things... maybe I am doing something real wrong ;=() 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
[Flightgear-devel] unusual behaviour, possibly missing cmake options?
I did my first CMake today on OpenSuSE 11.4 on a new PC, that is different than the one I normally use for FGFS, it uses a ATI Radeon Graphics (RS880 9714) rather than Nvidia cards I normally install. The cmake worked once I realised the CMAKE_PREFIX_PATH needs trailing slash on the directory paths. FWIW - PLIB, OpenAL, OSG, Boost and everything else is installed from RPM repositories. SimGear $ cmake -DCMAKE_INSTALL_PREFIX=/opt/SimGear/simgear-2.6/ -DCMAKE_PREFIX_PATH=/usr/ ../simgear/ FlightGear $ cmake -DCMAKE_INSTALL_PREFIX=/opt/FlightGear/flightgear-2.6 -DCMAKE_PREFIX_PATH=/usr/;/opt/SimGear/simgear-2.6/ ../flightgear/ So with everything compiled, linked and installed, when I run fgfs I get; $ bin/fgfs --fg-root=/opt/FlightGear/fgdata --log-level=DEBUG fgfs: xcb_io.c:507: _XReply: Assertion `!dpy-xcb-reply_data' failed. Aborted $ This looks like something to do with X11, anyone got any ideas on what could possibly be missing? cheers S. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terragear memory usage issue
Hi all, I am currently build a large chunk of scenery for SE Australia and have found a problem with terragear's memory usage. most of the data I am building is low quality until I get to around S30 to S35 however I have only gotten to S36 using the following command ad the memory usage of terragear is out at 5.5G. This seams very excessive and at this rate will consume all physical and swap in my box long before completion. The command used is: fgfs-construct --work-dir=. --output-dir=Scenery/Terrain --lon=140 --lat=-20 --xdist=15 --ydist=35 AirportArea AirportObj SRTM2-Australia-3 Sand Freeways Trunk_Freeways Tertiary_Roads Service_Roads Secondary_Roads Primary_Roads Railroads Residential_Roads watercourcelines watercourceareas builtupareas mainlands lakes reservouirs is it not appropriate to issue a build of such a large area? should I use smaller chunks? should terragear not be releasing the memory after building a tile? Jason -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
