Re: [Flightgear-devel] CMake question simgear include option
On 14 Feb 2013, at 18:58, HB-GRAL flightg...@sablonier.ch wrote: With simple -DCMAKE_INSTALL_PREFIX it finds the custom location of the headers and libs without any other option, but when I add -DSIMGEAR_INCLUDE_DIR=/path/to/include it takes the headers from this location, but not the libs anymore, it falls back to another simgear install on my system (which is in path). So I need to remove default simgear from my path, and then cmake works perfect. Sometimes I wonder with what things I can struggle with flightgear compilation and why only ME have such problems. ;-) Avoid setting the include path directly, would be my advice. If you want to use different simgear builds, then keep the completely separate. Eg, I have: ~/FGFS/ simgear flightgear fgBuild # configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist sgBuild # configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist dist fgBuild2# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist2 sgBuilld2 # configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist2 dist2 And this works fine for me, the different diet trees can have totally different version / config options since there is no overlap at all. James -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake question simgear include option
Hi James Thanks, yes, am aware of this kind of separation. But I thought: Why does cmake configuration make it possible to link against an osg include and lib dir for every part, while simgear has only a an option for headers and not the libs ?. And then when you set the simgear include dir, why does simgear link against system path libs and not against cmake install prefix? What speaks against linking the libs? Or what speaks against keeping this simgear include option away? I don't get the logic behind this, and of course me I do not run into real problems because of this, I am just a bit curious about what's behind this option setting. -Yves Am 15.02.2013 um 09:48 schrieb James Turner zakal...@mac.com: On 14 Feb 2013, at 18:58, HB-GRAL flightg...@sablonier.ch wrote: With simple -DCMAKE_INSTALL_PREFIX it finds the custom location of the headers and libs without any other option, but when I add -DSIMGEAR_INCLUDE_DIR=/path/to/include it takes the headers from this location, but not the libs anymore, it falls back to another simgear install on my system (which is in path). So I need to remove default simgear from my path, and then cmake works perfect. Sometimes I wonder with what things I can struggle with flightgear compilation and why only ME have such problems. ;-) Avoid setting the include path directly, would be my advice. If you want to use different simgear builds, then keep the completely separate. Eg, I have: ~/FGFS/ simgear flightgear fgBuild# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist sgBuild# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist dist fgBuild2# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist2 sgBuilld2# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist2 dist2 And this works fine for me, the different diet trees can have totally different version / config options since there is no overlap at all. James -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake question simgear include option
On Fri, 15 Feb 2013 08:48:59 +, James wrote in message 954f9f95-7614-4c0e-a82f-3b589fa4e...@mac.com: On 14 Feb 2013, at 18:58, HB-GRAL flightg...@sablonier.ch wrote: With simple -DCMAKE_INSTALL_PREFIX it finds the custom location of the headers and libs without any other option, but when I add -DSIMGEAR_INCLUDE_DIR=/path/to/include it takes the headers from this location, but not the libs anymore, it falls back to another simgear install on my system (which is in path). So I need to remove default simgear from my path, and then cmake works perfect. Sometimes I wonder with what things I can struggle with flightgear compilation and why only ME have such problems. ;-) Avoid setting the include path directly, would be my advice. If you want to use different simgear builds, then keep the completely separate. Eg, I have: ~/FGFS/ simgear flightgear ..these above (SGFG) are your one git source tree? fgBuild # configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist sgBuild # configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist dist fgBuild2# configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist2 sgBuilld2 # configured with CMAKE_INSTALL_PREFIX=~/FGFS/dist2 dist2 ..and dist dist2 are 2 separate build and install trees that you feed from your one git tree? And this works fine for me, the different diet trees can have totally different version / config options since there is no overlap at all. James -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake problem
On Friday, November 23, 2012 14:33:58 Renk Thorsten wrote: I'm just trying to get a working devel environment on my new machine, and I've succeeded in compiling simgear, but flightgear refuses the cmake configuration. Basically I want to have the simgear libs inside a user directory and not system-wide. So what I did is cloning the repositories, changing to separate build directories and using cmake ../../simgear -DCMAKE_INSTALL_PREFIX:PATH=/home/fgfs/FGLib followed by make CXXFLAGS=-s -O3 make install This created /home/fgfs/FGLib/lib64 /home/fgfs/FGLib/include directories which contain all the hxx files and the lib64/ directory contains libSimGearCore.a libSimGearScene.a, i.e things look normal. When I change to my flightgear build directory and do cmake ../../flightgear I get Cannot find SimGear includes! (Forgot 'make install' for SimGear?) Compile INSTALL SimGear before configuring FlightGear. When using non-standard locations, use 'SIMGEAR_DIR' to configure the SimGear location. which is as expected, so I do cmake ../../flightgear -DSIMGEAR_DIR:PATH=/home/fgfs/FGLib Hi Thorsten, I have a similar setup and I do set -D CMAKE_PREFIX_PATH=/path/to/OpenSceneGraph3;/path/to/plib;/path to/simgear;/path/to/openrti along with CMAKE_INSTALL_PREFIX:PATH of course. That goes for simgear too, since I have multiple OSG builds. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake problem
On Fri, 2012-11-23 at 12:33 +, Renk Thorsten wrote:
cmake ../../flightgear -DSIMGEAR_DIR:PATH=/home/fgfs/FGLib
Hi,
Try -
$ export SIMGEAR_DIR=/home/fgfs/FGLib \
cmake ../../flightgear
In FG/CMakeModules/FindSimGear.cmake you will find
HINTS $ENV{SIMGEAR_DIR}
Note the 'ENV', so it expects it to be in
the environment...
What you did WOULD work if you added -
HINTS $ENV{SIMGEAR_DIR} ${SIMGEAR_DIR}
But this may still fail, since you say it is
installed in -
/home/fgfs/FGLib/lib64
And the 'find' module has -
PATH_SUFFIXES ${CMAKE_INSTALL_LIBDIR} libs64 \
libs libs/Win32 libs/Win64
But 'perhaps' CMAKE_INSTALL_LIBDIR will include
a suffix of 'lib64'... not sure...
Another 'trick' to try is adding
-DCMAKE_PREFIX_PATH=/home/fgfs/FGLib
but this is not always certain...
HTH,
Regards,
Geoff.
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake problem
On 23 Nov 2012, at 12:33, Renk Thorsten wrote: When I change to my flightgear build directory and do cmake ../../flightgear Use the same CMAKE_INSTALL_PREFIX for everything, and it will all work out. No need to set SIMGEAR_DIR or anything. If you *have* set SIMGEAR_DIR or other settings, I'd recommend erasing your build directory and running cmake from clean - it 'remembers' previous values in the build dir's cache. And of course, use the same CMAKE_INSTALL_PREFIX when configuring + installing OSG. As I said, if you do that, everything else should be automatic - no need for environment variables or anything else. James -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake problem
If you *have* set SIMGEAR_DIR or other settings, I'd recommend erasing your build directory and running cmake from clean - it 'remembers' previous values in the build dir's cache. Ah, that's how it's supposed to be... I've now hacked my way through by adding the path explicitly to FindSimGear.cmake and finally the compilation ran through - well, I somehow had to set the path to libXmu explicitly, which caused weird problems down the line - I'll erase and redo it as you suggest later then. But I guess I'm getting there in the end. Thanks, * Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake equivalent to --with-osg=/some/path
On Wed, 2012-02-08 at 11:35 +, Jon Stockill wrote: I'm currently updating some jenkins build scripts for cmake rather than autoconf, and I'm having problems getting the build to link against local copies of all the dependencies. Is there a simple way of specifying where to look for these rather than having to specify the path to each individual library file (which from the cmake output seems like it might be the only way). Hi Jon, A HOT extract from my current 1.3.8 'makefg' script ;=)) Not yet published as still testing some options like - FGCM_OPTS=$FGCM_OPTS -D JPEG_FACTORY:BOOL=ON But for the dependencies OSG, SG, and the recently added PLIB when only installed 'locally'... ADDPLIBDIRS=0 # If PLIB is installed locally, then ADDPLIBDIRS=1 FGCM_OPTS=$FGCM_OPTS -D CMAKE_VERBOSE_MAKEFILE=TRUE if [ $ADDPLIBDIRS = 1 ]; then FGCM_OPTS=$FGCM_OPTS -D PLIB_LIBRARIES=$INSTALL_DIR_PLIB/lib FGCM_OPTS=$FGCM_OPTS -D PLIB_INCLUDE_DIR= $INSTALL_DIR_PLIB/include fi FGCM_OPTS=$FGCM_OPTS -D CMAKE_INSTALL_PREFIX=$INSTALL_DIR_FGFS For SG installed locally I use an export... like makefg: Done 'export SIMGEAR_DIR=/media/Disk2/FG/fg20/install/simgear' For OSG installed locally I use an export... like makefg: Done 'export OSG_DIR=/media/Disk2/FG/fg20/install/OSGtrunk' then... echo2 $BN: Will do 'cmake $FGCM_OPTS $FGFS_SOURCE_PATH' cmake $FGCM_OPTS $FGFS_SOURCE_PATH The actual cmake command is quite simple - makefg: Will do 'cmake -D CMAKE_VERBOSE_MAKEFILE=TRUE \ -D CMAKE_INSTALL_PREFIX=/media/Disk2/FG/fg20/install/flightgear \ /media/Disk2/FG/fg20/flightgear' I had tried setting SG LIBRARIES and INCLUDE, like PLIB, but this did not work for me - if [ $ADDSGDIRS = 1 ]; then FGCM_OPTS=$FGCM_OPTS -D SIMGEAR_LIBRARIES= $INSTALL_DIR_SIMGEAR/lib FGCM_OPTS=$FGCM_OPTS -D SIMGEAR_INCLUDE_DIR= $INSTALL_DIR_SIMGEAR/include fi Not sure why this fails... maybe it should be like - SIMGEAR_LIBRARIES:PATH=$INSTALL_DIR_SIMGEAR/lib or something... And also had some success with - FGCM_OPTS=$FGCM_OPTS -D CMAKE_PREFIX_PATH=$INSTALL_DIR_SIMGEAR but seemed unnecessary once I do the SIMGEAR_DIR 'export'... And more or less the same for terragear-cs except no need for OSG stuff... HTH, but maybe other with more cmake savvy can do better ;=)) Regards, Geoff. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake equivalent to --with-osg=/some/path
Hi, There is a shortcut if dependencies and results are all in the same directory prefix: -DCMAKE_INSTALL_PREFIX=directory This may not be suitable for jenkins. Olaf Flebbe o...@oflebbe.de Am 08.02.2012 um 12:35 schrieb Jon Stockill: I'm currently updating some jenkins build scripts for cmake rather than autoconf, and I'm having problems getting the build to link against local copies of all the dependencies. Is there a simple way of specifying where to look for these rather than having to specify the path to each individual library file (which from the cmake output seems like it might be the only way). -- Jon Stockill li...@stockill.net -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake windows
I have added the path for SIMGEAR_INCLUDE_DIR, and now the error message is:- looking for static Simgear libraries looking for version: 2.5.0 CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_LIBRARIES SIMGEAR_VERSION_OK) (Required is at least version 2.5.0) Call Stack (most recent call first): C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE) CMakeModules/FindSimGear.cmake:229 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:218 (find_package) Configuring incomplete, errors occurred! Alan-- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake windows
Problem solved, and sorry for the noise. I had forgotten to change CMAKE_INSTALL_PREFIX when configuring simgear. Alan From: Alan Teeder Sent: Tuesday, December 20, 2011 1:29 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cmake windows I have added the path for SIMGEAR_INCLUDE_DIR, and now the error message is:- looking for static Simgear libraries looking for version: 2.5.0 CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_LIBRARIES SIMGEAR_VERSION_OK) (Required is at least version 2.5.0) Call Stack (most recent call first): C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE) CMakeModules/FindSimGear.cmake:229 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:218 (find_package) Configuring incomplete, errors occurred! Alan -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
Hi, I updated README.cmake with Windows instructions. Could a native English speaker review my spelling and grammar ? Regards, -Fred -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
Thanks Fred. It looks fine. Alan (who failed his French O Level exams 3 times!) -Original Message- From: Frederic Bouvier Sent: Friday, November 11, 2011 1:08 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] cmake Hi, I updated README.cmake with Windows instructions. Could a native English speaker review my spelling and grammar ? Regards, -Fred -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On Mon, 2011-11-07 at 18:26 +, James Turner wrote:
On 7 Nov 2011, at 17:07, Martin Spott wrote:
Ok, I conclude: LIB_POSTFIX im Simgear doesn't work as expected ;-/
I think we have a 'thinko' in the module - looking at the code, we're using:
install (TARGETS ${libName} ARCHIVE DESTINATION lib${LIB_SUFFIX})
... my guess is if this was LIB_POSTFIX instead, it would do exactly what you
want ... set it to '64' and simgear will install to lib64
But I also suspect there's a smarter, automatic way to deal with this by
default.
There is:
IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
SET(LIB_POSTFIX 64 CACHE STRING suffix for 32/64 dir placement)
MARK_AS_ADVANCED(LIB_POSTFIX)
ENDIF()
IF(NOT DEFINED LIB_POSTFIX)
SET(LIB_POSTFIX )
ENDIF()
Erik
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On Tue, 08 Nov 2011 10:03:42 +0100, Erik wrote in message
1320743022.2034.0.camel@Raptor:
On Mon, 2011-11-07 at 18:26 +, James Turner wrote:
On 7 Nov 2011, at 17:07, Martin Spott wrote:
Ok, I conclude: LIB_POSTFIX im Simgear doesn't work as
expected ;-/
I think we have a 'thinko' in the module - looking at the code,
we're using:
install (TARGETS ${libName} ARCHIVE DESTINATION
lib${LIB_SUFFIX})
... my guess is if this was LIB_POSTFIX instead, it would do
exactly what you want ... set it to '64' and simgear will install
to lib64
But I also suspect there's a smarter, automatic way to deal with
this by default.
There is:
IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
SET(LIB_POSTFIX 64 CACHE STRING suffix for 32/64 dir placement)
MARK_AS_ADVANCED(LIB_POSTFIX)
ENDIF()
IF(NOT DEFINED LIB_POSTFIX)
SET(LIB_POSTFIX )
ENDIF()
Erik
..and this still gives us the ability to call
our binaries e.g. fgfs-w-sdl-wo-osg?
--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On Tue, 2011-11-08 at 11:07 +0100, Arnt Karlsen wrote: On Tue, 08 Nov 2011 10:03:42 +0100, Erik wrote in message IF(CMAKE_SIZEOF_VOID_P MATCHES 8) SET(LIB_POSTFIX 64 CACHE STRING suffix for 32/64 dir placement) MARK_AS_ADVANCED(LIB_POSTFIX) ENDIF() IF(NOT DEFINED LIB_POSTFIX) SET(LIB_POSTFIX ) ENDIF() Erik ..and this still gives us the ability to call our binaries e.g. fgfs-w-sdl-wo-osg? Sure it should only affect the libraries being build and installed Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On Tue, 08 Nov 2011 11:15:50 +0100, Erik wrote in message 1320747350.5635.0.camel@Raptor: On Tue, 2011-11-08 at 11:07 +0100, Arnt Karlsen wrote: On Tue, 08 Nov 2011 10:03:42 +0100, Erik wrote in message IF(CMAKE_SIZEOF_VOID_P MATCHES 8) SET(LIB_POSTFIX 64 CACHE STRING suffix for 32/64 dir placement) MARK_AS_ADVANCED(LIB_POSTFIX) ENDIF() IF(NOT DEFINED LIB_POSTFIX) SET(LIB_POSTFIX ) ENDIF() Erik ..and this still gives us the ability to call our binaries e.g. fgfs-w-sdl-wo-osg? Sure it should only affect the libraries being build and installed Erik ..ok, my understanding is and the binary names too, so differently configurated builds can be installed _alongside_ each other, for e.g. for benchmarking distro builds, e.g. /usr/bin/fgfs-2.6.2-1 against /usr/bin/fgfs-2.6.2-1-with-tire-rubber-drawing-on-runways-n-taxiways-fix and or /usr/bin/fgfs-2.6.2-1-with-osg3.4, e.g. distro people might like to try use some new etc other library in FG to fit their other stuff, or to debug own FG distro packaging. _Etc_. Not tested yet with cmake. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
Jon Stockill wrote: On 04/11/11 00:00, Martin Spott wrote: Jon Stockill wrote: Simgear doesn't seem to install to the correct directory on 64 bit systems any more - there doesn't seem to be any way to tell it to use /usr/lib64 instead of /usr/lib That's in LIB_POSTFIX. Try: # ~ cmake -D CMAKE_INSTALL_PREFIX=/usr -D LIB_POSTFIX=64 [...] OK, just tried that (after a make clean first just to be sure), it still installs to /usr/lib (and neither ccmake nor cmake -LH make any mention of that option). Ok, I conclude: LIB_POSTFIX im Simgear doesn't work as expected ;-/ Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On 7 Nov 2011, at 17:07, Martin Spott wrote:
Ok, I conclude: LIB_POSTFIX im Simgear doesn't work as expected ;-/
I think we have a 'thinko' in the module - looking at the code, we're using:
install (TARGETS ${libName} ARCHIVE DESTINATION lib${LIB_SUFFIX})
... my guess is if this was LIB_POSTFIX instead, it would do exactly what you
want ... set it to '64' and simgear will install to lib64
But I also suspect there's a smarter, automatic way to deal with this by
default.
James
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake osx
Am 05.11.11 03:27, schrieb Roland Häder: On Sat, 2011-11-05 at 01:31 +0100, HB-GRAL wrote: Hi James I successfully built simgear/flightgear today with cmake 2.8.4 and OSX 10.6.8. There have been some small changes I added to CMakeLists for sg/fg: SET(CMAKE_CXX_FLAGS -arch i386) and SET(CMAKE_C_FLAGS -arch i386). I am sure there is a better way to set this flags with cmake. Many thanks, Cheers, Yves Hi Yves, yes there is. Use environmental variables. E.g. create a script named reconfigure.sh and put this in: #!/bin/sh CFLAGS=-g -O3 -fPIC -arch i386 CXXFLAGS=-g -O3 -fPIC -arch i386 cmake ../../simgear \ -DJPEG_FACTORY=1 \ -DCMAKE_INSTALL_PREFIX=/opt #[EOF] Hope this works. Regards, Roland Hi Roland, yes this works well, though I had to change to export CFLAGS= and I used also -O2. Now it is time to have a small yves-osx-fg/sg-script here, gitpull-export-cmake-make-makeinstall, nice. Maybe how to set this flags for OSX should go to the readme once. I think some OSX users will end up with linking errors because simgear compiles well with x86_64, but then you run into a lot of problems trying to compile flightgear, on OSX. Btw. I tried also to set the flags via ccmake like I do it for OSG, but unfortunately without success. Sorry for my shortcomings with cmake, I am very fixated on the old build system probably, and now it so easy with cmake ;-) Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake osx
On 5 Nov 2011, at 11:25, HB-GRAL wrote: Maybe how to set this flags for OSX should go to the readme once. I think some OSX users will end up with linking errors because simgear compiles well with x86_64, but then you run into a lot of problems trying to compile flightgear, on OSX. Btw. I tried also to set the flags via ccmake like I do it for OSG, but unfortunately without success. Sorry for my shortcomings with cmake, I am very fixated on the old build system probably, and now it so easy with cmake ;-) Setting the compile flags is fine, but there's a much better way, that CMake 'understands': -DCMAKE_OSX_ARCHITECTURES=i386 This is a proper CMake list, so you can (and I do, often): -DCMAKE_OSX_ARCHITECTURES=i386;x86_64 (quotes needed for bash) This will then produce fat builds automatically. If you build OSG with correct options, 'ppc' and 'ppc64' are also possible - of course assuming your PLIB, ALUT and so on are also built with suitable options! There are other 'core' CMake variables to set the OS-X SDK version and deployment target too, if you ever need those (sometimes I do) James -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake osx
Am 05.11.11 17:13, schrieb James Turner: On 5 Nov 2011, at 11:25, HB-GRAL wrote: Maybe how to set this flags for OSX should go to the readme once. I think some OSX users will end up with linking errors because simgear compiles well with x86_64, but then you run into a lot of problems trying to compile flightgear, on OSX. Btw. I tried also to set the flags via ccmake like I do it for OSG, but unfortunately without success. Sorry for my shortcomings with cmake, I am very fixated on the old build system probably, and now it so easy with cmake ;-) Setting the compile flags is fine, but there's a much better way, that CMake 'understands': -DCMAKE_OSX_ARCHITECTURES=i386 This is a proper CMake list, so you can (and I do, often): -DCMAKE_OSX_ARCHITECTURES=i386;x86_64 (quotes needed for bash) This will then produce fat builds automatically. If you build OSG with correct options, 'ppc' and 'ppc64' are also possible - of course assuming your PLIB, ALUT and so on are also built with suitable options! There are other 'core' CMake variables to set the OS-X SDK version and deployment target too, if you ever need those (sometimes I do) James Hi James, I tried to set -DCMAKE_OSX_ARCHITECTURES and also SDK and Deployment target, but unfortunately whithout success. I did something wrong with ccmake, I didn’t get it re-configured the right way. Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake osx
Am 05.11.11 20:25, schrieb HB-GRAL: Am 05.11.11 17:13, schrieb James Turner: On 5 Nov 2011, at 11:25, HB-GRAL wrote: Maybe how to set this flags for OSX should go to the readme once. I think some OSX users will end up with linking errors because simgear compiles well with x86_64, but then you run into a lot of problems trying to compile flightgear, on OSX. Btw. I tried also to set the flags via ccmake like I do it for OSG, but unfortunately without success. Sorry for my shortcomings with cmake, I am very fixated on the old build system probably, and now it so easy with cmake ;-) Setting the compile flags is fine, but there's a much better way, that CMake 'understands': -DCMAKE_OSX_ARCHITECTURES=i386 This is a proper CMake list, so you can (and I do, often): -DCMAKE_OSX_ARCHITECTURES=i386;x86_64 (quotes needed for bash) This will then produce fat builds automatically. If you build OSG with correct options, 'ppc' and 'ppc64' are also possible - of course assuming your PLIB, ALUT and so on are also built with suitable options! There are other 'core' CMake variables to set the OS-X SDK version and deployment target too, if you ever need those (sometimes I do) James Hi James, I tried to set -DCMAKE_OSX_ARCHITECTURES and also SDK and Deployment target, but unfortunately whithout success. I did something wrong with ccmake, I didn’t get it re-configured the right way. Cheers, Yves So you say, when I prepare the binaries for FGx on OSX I should use -DCMAKE_OSX_ARCHITECTURES=i386;x86_64 (and some months ago I used also deployment target 10.5 and SDK 10.5). I will go with this, also with your Alut Framework and the patched plib. The problem is, I have no 10.5 anymore to check it. But ppc and ppc64, well ... ;-) Thanks, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake osx
Am 05.11.11 20:46, schrieb HB-GRAL: Am 05.11.11 20:25, schrieb HB-GRAL: Am 05.11.11 17:13, schrieb James Turner: On 5 Nov 2011, at 11:25, HB-GRAL wrote: Maybe how to set this flags for OSX should go to the readme once. I think some OSX users will end up with linking errors because simgear compiles well with x86_64, but then you run into a lot of problems trying to compile flightgear, on OSX. Btw. I tried also to set the flags via ccmake like I do it for OSG, but unfortunately without success. Sorry for my shortcomings with cmake, I am very fixated on the old build system probably, and now it so easy with cmake ;-) Setting the compile flags is fine, but there's a much better way, that CMake 'understands': -DCMAKE_OSX_ARCHITECTURES=i386 This is a proper CMake list, so you can (and I do, often): -DCMAKE_OSX_ARCHITECTURES=i386;x86_64 (quotes needed for bash) This will then produce fat builds automatically. If you build OSG with correct options, 'ppc' and 'ppc64' are also possible - of course assuming your PLIB, ALUT and so on are also built with suitable options! There are other 'core' CMake variables to set the OS-X SDK version and deployment target too, if you ever need those (sometimes I do) James Hi James, I tried to set -DCMAKE_OSX_ARCHITECTURES and also SDK and Deployment target, but unfortunately whithout success. I did something wrong with ccmake, I didn’t get it re-configured the right way. Cheers, Yves So you say, when I prepare the binaries for FGx on OSX I should use -DCMAKE_OSX_ARCHITECTURES=i386;x86_64 (and some months ago I used also deployment target 10.5 and SDK 10.5). I will go with this, also with your Alut Framework and the patched plib. The problem is, I have no 10.5 anymore to check it. But ppc and ppc64, well ... ;-) Thanks, Yves Oh, and I used cmake -G Xcode and this one works fine too. What a nice day :-) Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On 4 Nov 2011, at 00:41, Jon Stockill wrote: I believe it's FG_DATA_DIR, as observed here: https://gitorious.org/fg/flightgear/commit/4b8ef9c3cf4f4f3565de3678cd733ad8067be6d9 Thanks - that worked (well, it returns the correct details when you run cmake with that option, I've yet to test the resulting binary). It's not mentioned anywhere in ccmake though. The problem is, I'm not sure how to document a variable, that is not an 'option' (options must be booleans, as I understand it) I'm also unsure (I had to guess) what the default value should be. I looked at the autoconf docs, and the answer seems to be /$PREFIX/lib/$PKGNAME, hence my defaulting to the same for cmake ... but I can use anything else sane that people prefer. James -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On 3 Nov 2011, at 23:05, Jon Stockill wrote: There's doesn't seem to be any way to enable the jpg-httpd server. (Under autoconf it was enabled by default if Simgear was built with jpeg factory support). -DJPEG_FACTORY=1 ... except, hmm, that only seems to exist for Simgear let me check that one :) make install no longer installs the manpages. Ooops, that's my fault indeed, will fix. Thanks for the feedback! James -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
Hi James, On 4 Nov 2011, at 00:41, Jon Stockill wrote: I believe it's FG_DATA_DIR, as observed here: https://gitorious.org/fg/flightgear/commit/4b8ef9c3cf4f4f3565de3678cd733ad8067be6d9 Thanks - that worked (well, it returns the correct details when you run cmake with that option, I've yet to test the resulting binary). It's not mentioned anywhere in ccmake though. The problem is, I'm not sure how to document a variable, that is not an 'option' (options must be booleans, as I understand it) I think it's the SET option. You can check MSVC_3RDPARTY_ROOT for an example. Regards, -Fred -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake osx
On Sat, 2011-11-05 at 01:31 +0100, HB-GRAL wrote: Hi James I successfully built simgear/flightgear today with cmake 2.8.4 and OSX 10.6.8. There have been some small changes I added to CMakeLists for sg/fg: SET(CMAKE_CXX_FLAGS -arch i386) and SET(CMAKE_C_FLAGS -arch i386). I am sure there is a better way to set this flags with cmake. Many thanks, Cheers, Yves Hi Yves, yes there is. Use environmental variables. E.g. create a script named reconfigure.sh and put this in: #!/bin/sh CFLAGS=-g -O3 -fPIC -arch i386 CXXFLAGS=-g -O3 -fPIC -arch i386 cmake ../../simgear \ -DJPEG_FACTORY=1 \ -DCMAKE_INSTALL_PREFIX=/opt #[EOF] Hope this works. Regards, Roland signature.asc Description: This is a digitally signed message part -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
Jon Stockill wrote: Simgear doesn't seem to install to the correct directory on 64 bit systems any more - there doesn't seem to be any way to tell it to use /usr/lib64 instead of /usr/lib That's in LIB_POSTFIX. Try: # ~ cmake -D CMAKE_INSTALL_PREFIX=/usr -D LIB_POSTFIX=64 [...] Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On Friday, November 04, 2011 01:05:25 Jon Stockill wrote: Have we changed the default data directory again? cmake outputs this: -- Using default data-dir: /usr/lib/FlightGear There doesn't appear to be any way to set it within ccmake or from te commandline. I believe it's FG_DATA_DIR, as observed here: https://gitorious.org/fg/flightgear/commit/4b8ef9c3cf4f4f3565de3678cd733ad8067be6d9 Cheers, Adrian -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On 04/11/11 00:00, Martin Spott wrote: Jon Stockill wrote: Simgear doesn't seem to install to the correct directory on 64 bit systems any more - there doesn't seem to be any way to tell it to use /usr/lib64 instead of /usr/lib That's in LIB_POSTFIX. Try: # ~ cmake -D CMAKE_INSTALL_PREFIX=/usr -D LIB_POSTFIX=64 [...] OK, just tried that (after a make clean first just to be sure), it still installs to /usr/lib (and neither ccmake nor cmake -LH make any mention of that option). -- Jon Stockill li...@stockill.net -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On 04/11/11 00:08, Adrian Musceac wrote: On Friday, November 04, 2011 01:05:25 Jon Stockill wrote: Have we changed the default data directory again? cmake outputs this: -- Using default data-dir: /usr/lib/FlightGear There doesn't appear to be any way to set it within ccmake or from te commandline. I believe it's FG_DATA_DIR, as observed here: https://gitorious.org/fg/flightgear/commit/4b8ef9c3cf4f4f3565de3678cd733ad8067be6d9 Thanks - that worked (well, it returns the correct details when you run cmake with that option, I've yet to test the resulting binary). It's not mentioned anywhere in ccmake though. -- Jon Stockill li...@stockill.net -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Hi Mathias, Thanks again for your reply, comments and suggestions... always very welcome and all taken constructively. And I hope you understand I am NOT the one just saying it 'does not work'... I _AM_ taking the time, trying to understand, HOW to make the windows cmake GUI work better... since that is what I perceive most windows users will use... I do continue to suggest at this time it certainly appears more 'work' than using say Fred's nice combined SG/FG MSVC build set... But first - 1. static OSG versus shared Ok, seems I can NOT convince you this is NOTHING to do with the fact that I am choosing to use static OSG as opposed to shared... But I would continue to try to assure you it is NOT! But OK, to try to help convince you the following NEW re-configuration of flightgear the cmake GUI was ONLY using the 'shared' libraries, so you will have no doubt ;=)) 2. linux versus windows I am sure you are aware that there is sort of a BIG philosophy GAP between linux/unix users, builders, developers, and those in windows... In very few sentences you can usually tell quite quickly which 'camp' a person belongs to ;=)) less clear with apple eaters... You put yourself firmly in the *nix with the simple statement - I don't care for all the gui builders.. OK, that is your *nix choice, and good on you! I know windows, and some MAC, developers, who do some amazing development things, and almost NEVER open the windows command prompt, or a 'terminal' ;=() everything is GUI GUI GUI... So please recognize that some people want, use, like, prefer, expect a GUI, whether you like them or not ;=)) And to me cross-platform means respecting that difference, and not trying to suggest one method is better than another... Having developed in windows for most of my life, since 16-bit MS Windows 3.01, although in DOS before that, and only in about the last 5 years or so installed and now use linux every day, so I suppose I try to walk down the middle road. And maybe my years with DOS, before the word GUI was even invented makes me very comfortable in a 'terminal'...but even there I do also like to use scripts a lot... My makefg Ubuntu script, while it still needs some tidying perhaps, is working WELL in linux. So seems no problem there now. Some initial problems with some paths, but now all sorted - HAPPINESS! In windows, I too INSISTS on using the GUI ;=(( It is the windows way... When you start the GUI on a NEW project, that is fill in where is the source, and where to build the binaries, it starts with a blank page, until you click [configure] the first time... The first page that appears has about 70 configuration items, marked in red, some filled in, and some not. Like it does seem to 'remember' some things from previous 'configures', and works out some others... So in effect you may only have to adjust about 5-10 initial items... then [configure] again... And the number of config items now jumps to about 97 or so, adding about 24 (8 x 3) OSG items in red... Of course as you become more savvy, with even the GUI, you can set the OSG_DIR in the environment, or run it with CMAKE_PREFIX_PATH... BUT not all windows users are so familiar with (a) setting the environment before running especially a GUI, or (b) running a GUI adding a command line which involves manually adjusting the desktop shortcut icon - not done! Of course cmake does put the cmake-gui.exe in the PATH, so (a) and or (b) are not so difficult... But anyway, in experimentation while I found setting the OSG_DIR first, and/or setting -DCMAKEPREFIX_PATH=path only succeeded in the OSG 'INCLUDE' directory parts, but NOT the actual OSGname_LIBRARY_DEBUG and OSGname_LIBRARY_RELEASE library files. So that left some 16 of 24 or so items to MANUALLY set... Now you have said a few times, in a few ways that - Before you do so the first time, come here and ask for help! Well here I am! How do I avoid this MANUAL step for the GUI? One alternative mentioned is to directly fix the CMakeCache.txt file, and CONTRARY to your suggestion, what you add in here will NOT be overwritten during the next GUI 'configure'... There are some lower sections of the file, with an 'INTERNAL' tag which I am sure ARE overwritten on each 'configure', but I found the recommendation on a cmake tutorial site to manually adjust the top 'user' portion of CMakeCache.txt, so this is 'normal'. In my case since this is my 2nd try at this, to see more clearly what cmake will automatically set versus what I must manually set, I am able to cut and paste the 8x3 OSG items from the previous run... easy... Now when I run 'configure' again, the number of item again JUMPS by 96 with - PLIB 7 x 3 items in red. SG 25 x 3 items in red. Since I am using the so called '3rdparty' system - that is there is a special root-build/3rdparty folder, which contains all installed simgear and plib includes and library
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Geoff I found the Windows Cmake procedure rather simpler than you (but still much more complicated than the simple Flightgear single MSVC project). Here again is the recipe, from my post of 18 Oct, to which you can add my now infamous step 12a from 19 Oct. Alan 1. Set up a work directory as described in http://wiki.flightgear.org/index.php/Building_Flightgear_-_Windows. (NOTE: this is now out of date as the 3rdparty , zlib and OSG etc are all ready to use at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ ) 2. Open the Cmake gui 3. Set “Where is the source code” and “Where to build the binaries” to C:/Flightgear/simgear” (or wherever you have put simgear) 4. Press the “Configure” button. The first time that the project is generated, Cmake will bring up a window asking which compiler you wish to use. Normally just accept Cmakes suggestion, and press Finish. Cmake will now do a check on your system and will produce a preliminary build configuration.´ 5. Check for errors in the red window. Cmake should have found OSG, zlib and your 3rdparty directories. 6. Set CMAKE_INSTALL_PREFIX to C:/Flightgear/install. This is probably not necessary for Windows XP, but is required for Windows 7 as the default (C:\Program Files) is protected. 7. Press “Configure” once more. Errors should all have gone. 8. Press “Generate”. Cmake will now write a windows sln and project files in the simgear directory. 9. Open C:\Flightgear\simgear\simgear.sln. MSVC should come up. Select Release (or debug if you need it) build and then build-all. 10. Once simgear has built successfully (there will be some warnings), build the INSTALL project. This will copy the simgear libraries and include files to C:flightgear\install. 11. Now repeat the Cmake process for flightgear. The directories to choose are C:/Flightgear/flightgear. 12. It is important to chose the same CMAKE_INSTALL_PREFIX, otherwise the simgear libraries will not be found. 13. Open C:\Flightgear\flightgear\flightgear.sln. As with simgear, build all, and then build INSTALL. 14. Flightgear and other executables should be in C:\Flightgear\install\bin. No doubt I have left something out, but this does describe the basic process. Step 12a If you get the error Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) (Required is at least version 2.5.0) Press Add Entry In the window that comes up set Name to SIMGEAR_VERSION_OK, Type to BOOL and tick the Value box. Press OK and continue. This kludge bypasses the broken Simgear version check. -- 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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Hi, On Friday, October 28, 2011 20:20:55 Geoff McLane wrote: 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... Ok, I do not know the win32 build too good: But why are you using pthreads on win32? Neither osg nor simgear/flightgear should need this. And at least for osg, how do you manage to make osg use pthreads on win32? Also why do you want to have osg statically linked? It's possible to build and use osg with just static libs. But the default and really best supported configuration of osg is using shared libraries. The basic architecture of model loaders within osg is built around shared objects dynamically loaded at runtime. So as I saied before, it's possible to make osg's reader/writers work with static libs, but we do *not* have any support for that in flightgear/simgear. You would need some scary linker tricks or some code changes to make this work and I am not aware of anything in that corner in flightgear/simgear. Also, if you use static osg libraries, linking with them is probably incomplete within our buildsystem. We assume that once we link against an osg library this dll already pulls in what it requires for itself. This is not the case for static libraries. To me this pretty much explaines that huge amount of hand changes you have to to with cmake. I would suggest not to try linking osg with static libs. Also I would suggest that you do not use pthreads on win32. Then, if you still have to do some of these scary changes to cmake like setting SIMGEAR_VERSION_OK=TRUE, please stop and return to here. Mathias -- 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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Sat, 2011-10-29 at 13:49 +0200, Mathias Fröhlich wrote: Hi, On Friday, October 28, 2011 20:20:55 Geoff McLane wrote: 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... Ok, I do not know the win32 build too good: But why are you using pthreads on win32? Neither osg nor simgear/flightgear should need this. And at least for osg, how do you manage to make osg use pthreads on win32? Also why do you want to have osg statically linked? It's possible to build and use osg with just static libs. But the default and really best supported configuration of osg is using shared libraries. The basic architecture of model loaders within osg is built around shared objects dynamically loaded at runtime. So as I saied before, it's possible to make osg's reader/writers work with static libs, but we do *not* have any support for that in flightgear/simgear. You would need some scary linker tricks or some code changes to make this work and I am not aware of anything in that corner in flightgear/simgear. Also, if you use static osg libraries, linking with them is probably incomplete within our buildsystem. We assume that once we link against an osg library this dll already pulls in what it requires for itself. This is not the case for static libraries. To me this pretty much explaines that huge amount of hand changes you have to to with cmake. I would suggest not to try linking osg with static libs. Also I would suggest that you do not use pthreads on win32. Then, if you still have to do some of these scary changes to cmake like setting SIMGEAR_VERSION_OK=TRUE, please stop and return to here. Mathias Hi Mathias, Thank you for your reply and ideas... and hope I can answer some things regarding Windows... And as usual, sorry in advance that this is so long... While I nearly always use 'shared' libraries in Ubuntu, when offered, such DLL implementations in Windows are just NOT so good... It means when you want to share the application with some other Windows person, or even copy it to a second, 3rd machine, you have to - (a) pack all the DLLs with the EXE, and you/they need to know how to set it up, or (b) you have to go to whole distance and pass them a Windows installer app, which will handle all this placement for them... using like NSIS, INNO, etc... Moreover even then, usually depending on the MSVC version used, and the runtime chosen, there still remains some incompatibilities even between the various versions of Windows... As you point out, OSG does fully support using static libraries, AND that support INCLUDES pulling in the desired set of plugins... see the USE_OSGPLUGIN(ac); MACRO... AND SimGear/FlightGear includes all this 'static' support, just by defining OSG_LIBRARY_STATIC the OSG macro pulls in the desired set of plugins... So in most ways it is no different, excepts for the massive convenience of not having to be concerned about DLLS being in the right place at runtime... Now whether pthreads is still needed for SG/FG, that I will have to check... maybe it is just some residual, old code... BUT I do notice in the Ubuntu compile/link that pthreads or pthread IS still part of the process, even in the cmake build... maybe this needs to be removed... One of the great things about using static libraries, is that the linker only extracts the required code, and only for any services/functions actually called... So it does no particular harm to link with this or that additional static library, even if nothing is used from it... nothing will be added to the executable... Ok, quickly looking in src/Main/bootstrap.cxx, I can see the code :- #ifdef PTW32_STATIC_LIB // Initialise static pthread win32 lib pthread_win32_process_attach_np (); #endif so, if pthreads is NOT required then this call should be REMOVED from the code. Now back to OSG, I do NOT think the changes I have had to make in the GUI have anything at all to do with whether using shared or static OSG... Yes, it does make a slight difference regarding the plugins, since in the static case, this set of plugins desired MUST be passed to the linker at link time... about 6 or 10 of them... But ok, I am willing and able to deal with that just so I can keep my convenience of using all 'static' libraries, where possible. And this static/shared question has got nothing to do with the big list of both PLIB, SimGear and OSG libraries that MUST get into the MSVC build files... I am lucky I can compare the CMakeCache.txt files from linux and windows... In linux, I can see all the SAME entries are there, like say - OSGTEXT_INCLUDE_DIR:PATH=/home/geoff/fg/fg16/install/OSG301/include
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Hi Geoff, On Saturday, October 29, 2011 18:21:29 Geoff McLane wrote: Thank you for your reply and ideas... and hope I can answer some things regarding Windows... And as usual, sorry in advance that this is so long... So, my disclaimer is that I do not have any win32 system running. I just heared - even if also not explicitly targeted to you - some complaints that this is 'all not working'. That is also not the way I try to think about such problems. What I want is some help to find the real problem. What I can offer is asking questions and suggesting things. Proably with some background I also have also with win32 systems. But I do not own one and at work where I have access to some, I do not want to play flightgear. While I nearly always use 'shared' libraries in Ubuntu, when offered, such DLL implementations in Windows are just NOT so good... It means when you want to share the application with some other Windows person, or even copy it to a second, 3rd machine, you have to - (a) pack all the DLLs with the EXE, and you/they need to know how to set it up, or (b) you have to go to whole distance and pass them a Windows installer app, which will handle all this placement for them... using like NSIS, INNO, etc... Yes. I am aware of that. This is pretty much the same on *nix. It's just more unusual that you move built binaries from one machine to the other without a system installer. Moreover even then, usually depending on the MSVC version used, and the runtime chosen, there still remains some incompatibilities even between the various versions of Windows... Yep. But that does not change with a static build I think. Or do you also statically link against msvcrt? I believe you still need to make sure that the redestributible runtime is installed on the machine you use. Or alternatively unpack the msvcrt and friends into a directory named like the manifest hash beside the binary. Then the runtime is found even when not installed in the system. As you point out, OSG does fully support using static libraries, AND that support INCLUDES pulling in the desired set of plugins... see the USE_OSGPLUGIN(ac); MACRO... AND SimGear/FlightGear includes all this 'static' support, just by defining OSG_LIBRARY_STATIC the OSG macro pulls in the desired set of plugins... Ok, I did a quick grep over simgear and did not find this ... But it's in flightgear. Ok - I was not aware of that. Now whether pthreads is still needed for SG/FG, that I will have to check... maybe it is just some residual, old code... Yes, for *nix. Since this is the primary thread library you need to use to start a thread on *nix. but on win32 this should not be needed. There is a native win32 implementation in OpenThreads as well as in osg. Ok, quickly looking in src/Main/bootstrap.cxx, I can see the code :- #ifdef PTW32_STATIC_LIB // Initialise static pthread win32 lib pthread_win32_process_attach_np (); #endif so, if pthreads is NOT required then this call should be REMOVED from the code. Ok. Now back to OSG, I do NOT think the changes I have had to make in the GUI have anything at all to do with whether using shared or static OSG... Yes, it does make a slight difference regarding the plugins, since in the static case, this set of plugins desired MUST be passed to the linker at link time... about 6 or 10 of them... Yes, also it's not sufficient to just link with some parts of osg. 1. The order of the osg libraries gets important. 2. Some of them might itself depend on libraries that are just already linked with the dlls otherwise. These libraries must b included in the link process. I still believe that already some of the cmake tests regarding osg or simgear fails due to some of these problems. So all the hand changes you tell about are changes that just paper over such kind of problem I think. And sure these changes are overwritten by cmake all the time since they were never intented to be changed by the user. So if I understand the real problem, I am pretty sure cmake is a net win since plenty of build system stuff is now shared across *all* platforms. But in windows, EACH of these variable MUST be setup one by one, in the GUI... No, this must not happen. We need to find out what is going wrong here. This is the real reason of what is going wrong. I have not done the counts exactly, but that is like SimGear 25 x 3 items to setup OSG 8 x 3 items to setup PLIB 7 x 3 items to setup :-) Puh. I would never do that! Before you do so the first time, come here and ask for help! RANT begins ;=() :-) You don't do any rants with the following. At least not to me. I hope that I did not sour too hars with the past mail ... Then on 2010/10/19 Jame proposed cmake. His words at the time - These files are completely orthogonal to the existing autoconf/automake build... and My motivation for creating these was my Mac Xcode projects... and even asking developers to
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
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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Tue, 2011-10-25 at 18:47 +0100, James Turner wrote:
On 25 Oct 2011, at 15:20, Geoff McLane wrote:
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?
The problem is you've confused me, with all the discussion :) So it would
help, to be able to see exactly the commands, all of them, in one place -
maybe upload your scripts to someplace? Then I can get an overview of what
you're doing.
Hi James,
This problem was happening in BOTH Ubuntu linux,
and in XP WIN32...
BUT at least in Ubuntu, I think some of the problem
was that I was NOT deleting the CMakeCache.txt file
each time I modified the script for another try...
Remember the abort I was getting was :-
Could NOT find SimGear (missing: SIMGEAR_VERSION_OK)
Now I seem to have found a combination that works -
(a) Setting the environment -
makefg: Done export SIMGEAR_DIR=/media/Disk2/FG/fg17/install/simgear
AND
(b) adding SIMGEAR_INCLUDE_DIR
makefg: Will do 'cmake -D CMAKE_BUILD_TYPE=Release \
-D CMAKE_CXX_FLAGS=-O3 -D LIB_POSTFIX= \
-D CMAKE_INSTALL_PREFIX:PATH=/media/Disk2/FG/fg17/install/fgfs \
-D ENABLE_RTI=OFF -D CMAKE_VERBOSE_MAKEFILE=TRUE \
-D SIMGEAR_LIBRARIES=/media/Disk2/FG/fg17/install/simgear/lib \
-D SIMGEAR_INCLUDE_DIR=/media/Disk2/FG/fg17/install/simgear/include\
.'
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 ;=((
Linking CXX executable fgjs
cd /media/Disk2/FG/fg17/fgfs/source/src/Input /usr/bin/cmake -E
cmake_link_script CMakeFiles/fgjs.dir/link.txt --verbose=1
/usr/bin/c++ -O3 -Wall -D_REENTRANT -O3 -DNDEBUG
CMakeFiles/fgjs.dir/fgjs.cxx.o CMakeFiles/fgjs.dir/jsinput.cxx.o
CMakeFiles/fgjs.dir/jssuper.cxx.o -o fgjs -rdynamic -Wl,-Bstatic
-lplibpuaux -lplibjs -lplibfnt -lplibssg -lplibsg -lplibpu -lplibul
-Wl,-Bdynamic
CMakeFiles/fgjs.dir/fgjs.cxx.o: In function
`fgScanForOption(std::basic_stringchar, std::char_traitschar,
std::allocatorchar const, std::basic_stringchar,
std::char_traitschar, std::allocatorchar const)':
fgjs.cxx:(.text+0x12b): undefined reference to
`sg_gzifstream::sg_gzifstream(std::basic_stringchar,
std::char_traitschar, std::allocatorchar const,
std::_Ios_Openmode)'
fgjs.cxx:(.text+0x13c): undefined reference to
`logstream::initGlobalLogstream()'
fgjs.cxx:(.text+0x142): undefined reference to `logbuf::logClass'
fgjs.cxx:(.text+0x15f): undefined reference to
`skipcomment(std::basic_istreamchar, std::char_traitschar )'
fgjs.cxx:(.text+0x21f): undefined reference to
`skipcomment(std::basic_istreamchar, std::char_traitschar )'
fgjs.cxx:(.text+0x295): undefined reference to `gzfilebuf::~gzfilebuf()'
fgjs.cxx:(.text+0x2ca): undefined reference to `logbuf::logPriority'
[snip]
This is missing SG gzip and logbuf, and can NOT see
ANY SG libraries in the link, like -lsgdebug,
etc...very puzzling???
Maybe this is related to EVENT_INPUT which
defaults ON for APPLE, but has a comment
for linux -
elseif(CMAKE_SYSTEM_NAME MATCHES Linux)
# disabled while DBus / HAL / udev issues are decided
#set(EVENT_INPUT_DEFAULT 1)
and later
option(EVENT_INPUT
Set to ON to build FlightGear with event-based Input support
${EVENT_INPUT_DEFAULT})
but maybe this has nothing to do with it...
Anyway, out of time for exploration tonight,
but look forward to any suggestions for
continuing tomorrow...
As mentioned I am trying to update my script to
use CMake... The previous versions of the script are
published here -
http://geoffair.org/fg/fgfs-052.htm
BUT because this 'cmake' version 1.3.5 is
not yet fully tested, and sometimes failing,
I have not yet published it on that page, but a
copy of it is here for testing :-
http://geoffair.org/tmp/makefg
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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Monday, October 24, 2011 16:53:23 James Turner wrote: 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, and thanks for updating the readme. I may be blind or just stupid, but I can't find a way of setting CMAKE_PREFIX_PATH in KDevelop that works. Adding it to environment variables does not do anything, and cmake fails to find the libraries. Do you, or anybody else, know how to get KDevelop to use custom paths the way cmake does with -D CMAKE_PREFIX_PATH ? I'm using KDevelop 4.01 on Debian Squeeze. Thanks, Adrian -- 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 25 Oct 2011, at 09:39, Adrian Musceac wrote: Hi James, and thanks for updating the readme. I may be blind or just stupid, but I can't find a way of setting CMAKE_PREFIX_PATH in KDevelop that works. Adding it to environment variables does not do anything, and cmake fails to find the libraries. Do you, or anybody else, know how to get KDevelop to use custom paths the way cmake does with -D CMAKE_PREFIX_PATH ? I'm using KDevelop 4.01 on Debian Squeeze. It's a cmake variable, not an environment one, so I guess all I can really say is 'set it the same way you pass any other variable to cmake in Kdevelop' - but that's not much help, I appreciate! Note from the command line, you must not include a space between the -D and the cmake variable name, i.e I need to do: cmake ../source/dir -DCMAKE_PREFIX_PATH=/path/one;/path/two (the quotes are necessary if specifying multiple paths for me, otherwise bash treats the semi-colon as a command separator - depending on how Kdevelop invokes cmake, that may or may not be necessary for you) 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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
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!!!
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On 25 Oct 2011, at 15:20, Geoff McLane wrote: 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? The problem is you've confused me, with all the discussion :) So it would help, to be able to see exactly the commands, all of them, in one place - maybe upload your scripts to someplace? Then I can get an overview of what you're doing. 1. can NOT compile sgsound due to NOT finding AL/al.h 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? Seems like a bug in the FindOpenAL module (we use the standard CMake one) - might need to report it upstream. We can fork the script locally, and add support, but I wonder why other Windows users didn't report this. Maybe they all use Fred's standard dependencies package? 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... 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? The problem is library detection, not generation (so changing the postifx won't help - it only affects the libraries that are produced). Again it may be an issue with the FindZLib module on Windows - I don't run Windows so not really able to say. On Unix, CMake will use both the debug and release versions if it finds them, otherwise it will use the release (no suffix) version for everything. That's fine on Unix, but obviously not on Windows, since the runtimes clash as you described. 3. Question of library output directory 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 ;=)) Can't you just run 'make install'? The build locations are correct, if you want them to end up in their final home, you need to actually perform the install step. Assuming I understand what you're trying to achieve. 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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Geoff I see the same problem with windows cmake gui. My solution was to define SIMGEAR_VERSION_OK as boolean true in the flightgear cmake. This seems to bypass the bug and satisfy cmake. Alan -Original Message- From: Geoff McLane Sent: Sunday, October 23, 2011 6:47 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd) Hi All, HELP needed ;=(( Trying to compile the latest FG git, updated just hours ago, in Ubuntu 10.04, using CMake... ---snip CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:187 (find_package) -- 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)
Hi James, Thanks for your reply, and from Mathius and Alan... Does that help at all? Well, there is no doubt I could 'simplify' the situation by NOT appending an extra path items after 'install', but I should not have to! If I wanted such a 'simple' single install path, why not install those items to /usr/include or /usr/local/include, and /usr/lib or /usr/local/lib... and be done with it! But this implies you are ONLY going to have say ONE version of say OSG, or simgear installed, always building against it... 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 ;=)) And I also like your idea of building OUTSIDE the source tree... Will also get around to giving that a try... As to adding CMAKE_VERBOSE_MAKEFILE, I certainly like to see exactly WHAT is being passed to gcc, so will always keep this... And I know in the 'Release' build the LIB_POSTFIX is not required, since it already defaults to 'nothing', but should do no harm to add it... But the idea from Alan, in Windows, which I think is sort of 'cheating' ;=)) and that is to add a -D SIMGEAR_VERSION_OK=TRUE got me through the cmake configure step, but with some VERY ominous warnings from cmake, which does not look good for the final links - ... -- Configuring done WARNING: Target fgfs requests linking to directory /home/geoff/fg/fg16/install/simgear/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target metar requests linking to directory /home/geoff/fg/fg16/install/simgear/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target fgviewer requests linking to directory /home/geoff/fg/fg16/install/simgear/lib. Targets may link only to libraries. CMake is dropping the item. -- Generating done ... But ignoring those, the build still FAILED on the first compile for another reason - [ 0%] Building CXX object src/Airports/CMakeFiles/fgAirports.dir/apt_loader.cxx.o cd /home/geoff/fg/fg16/fgfs/source/src/Airports /usr/bin/c++ \ -DHAVE_CONFIG_H -O3 -Wall -D_REENTRANT -O3 -DNDEBUG \ -I/home/geoff/fg/fg16/install/OSG301/include -I/usr/include/AL \ -I/home/geoff/fg/fg16/install/simgear/include/simgear \ -I/home/geoff/fg/fg16/fgfs/source/src \ -I/home/geoff/fg/fg16/fgfs/source/src/Include \ -I/home/geoff/fg/fg16/fgfs/source \ -o CMakeFiles/fgAirports.dir/apt_loader.cxx.o -c \ /home/geoff/fg/fg16/fgfs/source/src/Airports/apt_loader.cxx In file included from /home/geoff/fg/fg16/fgfs/source/src/Airports/apt_loader.cxx:29: /home/geoff/fg/fg16/fgfs/source/src/Airports/apt_loader.hxx:28:30: error: simgear/compiler.h: No such file or directory /home/geoff/fg/fg16/fgfs/source/src/Airports/apt_loader.cxx:37:31: error: simgear/constants.h: No such file or directory ... etc, etc, etc This shows cmake getting the simgear 'include' directory WRONG! It is adding 'simgear' to the end when it should NOT! -I/home/geoff/fg/fg16/install/simgear/include/simgear I think that should be just -I/home/geoff/fg/fg16/install/simgear/include Having HIT this cmake barrier, I reverted to venerable automake, and FG built without problems ;=)) I will continue testing with CMake in Ubuntu, and will also give it a try in Windows, and thanks for all the effort in this regard, but I certainly do not feel it is quite the right time to fully dismantle the automake system ;=() Simply, any new system adopted should - (a) work in ALL cases, and (b) offer the SAME flexibility in the location of dependent library versions... Of course I understand this may take some effort to work out the correct cmake commands, and am willing to continue to seek this, but it should be achievable ;=)) Any new, further ideas welcome... I will certainly give them a try... Regards, Geoff. On Sun, 2011-10-23 at 20:44 +0100, James Turner wrote: On 23 Oct 2011, at 18:47, Geoff McLane wrote: Sorry, what am I doing wrong? I'm not sure *exactly* what you're doing wrong, but in general I would say you're over controlling things a little. I'm not clear why you are installing each component in a subdir of install - that's making your life complicated. If you simply installed OSG to /home/geoff/fg/fg16/install (as CMAKE_INSTALL_PREFIX when configuring OSG) then assuming you have (from Git) /home/geoff/fg/fg16/flightgear /home/geoff/fg/fg16/simgear you should simply need: cd /home/geoff/fg/fg16/ mkdir fgbuild mkdir sgbuild cd sgbuild cmake ../simgear -D
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
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 -- 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)
-Original Message- From: James Turner Sent: Monday, October 24, 2011 2:53 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd) 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 (if you are listening and I am not on your /dev/null list) Yes I am well aware that forcing SIMGEAR_VERSION_OK is bad practice, but in lieu of a proper fix it got my build process working. With the MSVC project build system Windows users have had to generate their own version.h file from version.h.in for some time now, so it was no surprise that Cmake had similar problems. I can send you files from my flightgear/cmake setup if these help. Let me know which files you need. I am still of the impression that Cmake is a backward step for Windows users. Perhaps you consider them unimportant, but flightgear is cross platform, and Windows is not an insignificant user base. Previously all that was necessary was to open C:\flightgear\flightgear\projects\FlightGear.sln and MSVC did everything - building both simgear and flightgear with one click of the button. Now it is necessary to set up (and get acquainted with !) Cmake, run Cmake generate and Cmake configure, open simgear.sln with MSVC select all-build followed by build install, and then repeat the Cmake + MSVC process with flightgear. Rant over. ;) Alan -- 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 Sat, 2011-10-22 at 16:03 +0100, James Turner wrote: If there's lingering queries about Cmake, or requests on the 'best' way to handle the transition, please let me know. Feedback on the README file would be appreciated too, or even commits / patches to improve it! CMake worked like a charm but I did notice that the special purpose FDM's don't get included anymore. I believe I did see it mentioned in the CMake configuration but leaving code out on a development system might introduce a chance of bit-rot. That said, I think some of the SP FDM's can be removed entirely since they've been superseded. Erik -- 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 23 Oct 2011, at 09:31, Erik Hofman wrote: CMake worked like a charm but I did notice that the special purpose FDM's don't get included anymore. I believe I did see it mentioned in the CMake configuration but leaving code out on a development system might introduce a chance of bit-rot. That said, I think some of the SP FDM's can be removed entirely since they've been superseded. The special purpose FDMs are disabled by default, it's one line to make them enabled by default of course! Actually, one of my post CMake build plans, is to make all the FDMs switchable at build-time, partly because I'm sick of all the compiler warnings from the UIUC / larcsim code, but also because at some point in the future we want the FDMs to be more 'modular' to the rest of FG - eg in their own thread or HLA-process, potentially. Knowing that the code builds cleanly with, for example, *just* the Null/UFO FDM selected would be interesting. So we will have ENABLE_YASIM, ENABLE_LARCSIM, ENABLE_JSBSIM and so on. Obviously I will keep the defaults for those to match the current expectations (well, maybe Larcsim could be off by default? Does anyone ever use it?) But you've convinced it's a good idea to have a Jenkins build, which has all the FDMs enabled, to avoid bit-rot in the special ones! Thanks for your feedback, 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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Sun, 2011-10-23 at 09:44 +0100, James Turner wrote: The special purpose FDMs are disabled by default, it's one line to make them enabled by default of course! Actually, one of my post CMake build plans, is to make all the FDMs switchable at build-time, partly because I'm sick of all the compiler warnings from the UIUC / larcsim code, but also because at some point in the future we want the FDMs to be more 'modular' to the rest of FG - eg in their own thread or HLA-process, potentially. Knowing that the code builds cleanly with, for example, *just* the Null/UFO FDM selected would be interesting. We had been thinking about that in the past but with the lack of a build server we decided that leaving them all in was the safest option. So we will have ENABLE_YASIM, ENABLE_LARCSIM, ENABLE_JSBSIM and so on. Obviously I will keep the defaults for those to match the current expectations (well, maybe Larcsim could be off by default? Does anyone ever use it?) I believe UIUC uses LaRCsim. I agree the UIUC code is becoming a problem since they used to develop in in house and dump a bunch of code in the FlightGear tree when there was still development in that area. I must admit I don't have a clue if we even are allowed to change or fix the UIUC code, and if there is a chance changes get overwritten when they decide to push another round of updates... But you've convinced it's a good idea to have a Jenkins build, which has all the FDMs enabled, to avoid bit-rot in the special ones! Ah great. Erik -- 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)
Hi All, HELP needed ;=(( Trying to compile the latest FG git, updated just hours ago, in Ubuntu 10.04, using CMake... First tried - .../source$ export OSG_DIR=/home/geoff/fg/fg16/install/OSG301 .../source$ cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS=-O3 \ -D LIB_POSTFIX= \ -D CMAKE_INSTALL_PREFIX:PATH=/home/geoff/fg/fg16/install/fgfs \ -D ENABLE_RTI=OFF -D CMAKE_VERBOSE_MAKEFILE=TRUE \ -D SIMGEAR_LIBRARIES=/home/geoff/fg/fg16/install/simgear/lib \ -D SIMGEAR_INCLUDE_DIR=/home/geoff/fg/fg16/install/simgear/include . Then tried - ../source$ export OSG_DIR=/home/geoff/fg/fg16/install/OSG301 ../source$ export SIMGEAR_DIR=/home/geoff/fg/fg16/install/simgear ../source$ cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS=-O3 \ -D LIB_POSTFIX= \ -D CMAKE_INSTALL_PREFIX:PATH=/home/geoff/fg/fg16/install/fgfs \ -D ENABLE_RTI=OFF -D CMAKE_VERBOSE_MAKEFILE=TRUE . And tried both the export AND setting SIMGEAR_INCLUDE_DIR... of course this is all in my makefg script, which I am trying to update to use CMake... But the cmake runs ended in - -- Git revision is 2bc5604797a55278c1a8fe51a1cc8d0bfe36675e -- libsvn found, enabling in terrasync -- /usr/include -- adding runtime JS dependencies -- /home/geoff/fg/fg16/install/simgear/include -- looking for version: 2.5.0 CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:187 (find_package) -- Configuring incomplete, errors occurred! The directory /home/geoff/fg/fg16/install/simgear/include contains drwxr-xr-x 21 geoff geoff 4096 2011-10-23 18:41 simgear and that was from a successful build of SG git using cmake a little time before... That directory in turn contains, among other things, - -rw-r--r-- 1 geoff geoff 29 2011-10-23 18:40 version.h with the value #define SIMGEAR_VERSION 2.5.0 And the file I think it is searching for, simgear/math/SGMath.hxx, is certainly there - -rw-r--r-- 1 geoff geoff 1495 2011-09-07 15:57 \ /home/geoff/fg/fg16/install/simgear/include/simgear/math/SGMath.hxx As can be see, I am using CMake version 2.8, actually 2.8.1 Sorry, what am I doing 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
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Hi, On Sunday, October 23, 2011 21:44:53 James Turner wrote: I'm not sure *exactly* what you're doing wrong, but in general I would say you're over controlling things a little. I'm not clear why you are installing each component in a subdir of install - that's making your life complicated. If you simply installed OSG to I for myself don't do that either, but if you do so - it seems not to be so uncommon - there was a recent mail that may help for you: http://sourceforge.net/mailarchive/message.php?msg_id=28102688 Greetings Mathias -- 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 Sat, Oct 22, 2011 at 10:03 AM, James Turner wrote: Hello again, Barring last-minute objections, I would like to declare CMake 'the' build system, from tomorrow onwards. Since my last email I've added a README.cmake to flightgear, and I'm working on ensuring the 'make dist' features of automake are replicated in CMake (via CPack) so when 2.6 time comes around, we don't have too many surprises. My plan is to disable the automake builds on Jenkins tomorrow (Sunday), and then start removing the automake build machinery, and the projects/ subdirectory, from the simgear and flightgear source trees. (I can create a Git tag prior to removing any files, if that's of interest?) If there's lingering queries about Cmake, or requests on the 'best' way to handle the transition, please let me know. Feedback on the README file would be appreciated too, or even commits / patches to improve it! It might be a bit extra work, but it would be good to take the source.tar.gz files that cmake creates, unpack them in a new directory and just make sure we can do a clean build from them. This always seems to expose a file or two, or a header that someone forgot to add to the automake.am so it never got included in the source distribution. (i.e. you could build from git just fine, but things were missing in the source distribution.) These are usually easy to fix, but it's good to catch them earlier rather than later. Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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)
-Original Message- From: James Turner Sent: Saturday, October 22, 2011 4:03 PM To: FlightGear developers discussions Subject: [Flightgear-devel] CMake, tomorrow (Sunday 23rd) If there's lingering queries about Cmake, or requests on the 'best' way to handle the transition, please let me know. Feedback on the README file would be appreciated too, or even commits / patches to improve it! Regards, James Already done for Windows Cmake gui. Did you miss it? Alan -- 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 22 Oct 2011, at 16:09, Curtis Olson wrote: It might be a bit extra work, but it would be good to take the source.tar.gz files that cmake creates, unpack them in a new directory and just make sure we can do a clean build from them. This always seems to expose a file or two, or a header that someone forgot to add to theautomake.am so it never got included in the source distribution. (i.e. you could build from git just fine, but things were missing in the source distribution.) These are usually easy to fix, but it's good to catch them earlier rather than later. Will do! Although, the CPack approach to this is rather different from automake - basically it packages *everything* in the source dir. I've added exclude rules for .git and .gitignore, but aside from that, everything from Git goes into the source tarball. Is there anything else that ought to be excluded? I can't imagine what that might be, but suggestions welcome. 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
Re: [Flightgear-devel] Cmake (soon)
Hi, On Tuesday, October 18, 2011 10:40:41 James Turner wrote: I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) Great thanks! Mathias -- 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 (soon)
There is a fault somewhere in Flightgear/Simgear cmake which makes this happen from time to time. Here is a quick fix. Step 12a If you get the error Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) (Required is at least version 2.5.0) Press Add Entry In the window that comes up set Name to SIMGEAR_VERSION_OK, Type to BOOL and tick the Value box. Press OK and continue. This bypasses the broken Simgear version check. Alan -Original Message- From: Rob Dosogne Sent: Tuesday, October 18, 2011 10:06 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cmake (soon) Thanks for the instructions, Alan. I tried this twice from scratch—SimGear configures builds just fine, but CMake gets stuck trying to configure FlightGear. I set CMAKE_INSTALL_PREFIX as you said, and building INSTALL seems to have copied SimGear into that directory, but CMake can't find it; any ideas? Git revision is 3rdparty files located in C:/FlightGear apr-1-config not found, implement manual search for APR Could NOT find LIBSVN (missing: LIBSVN_LIBRARIES LIBSVN_INCLUDE_DIR) C:/FlightGear/3rdParty.x64/include adding runtime JS dependencies C:/FlightGear/install/include looking for version: 2.5.0 CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) (Required is at least version 2.5.0) Call Stack (most recent call first): C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE) CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:179 (find_package) Configuring incomplete, errors occurred! cheers, Rob On Tue, Oct 18, 2011 at 09:41, Alan Teeder ajtee...@v-twin.org.uk wrote: It is about time that such a document was started, many thanks. However windows users will most likely use the CMake gui, which hides all that geeky command line stuff. For Cmake gui the following seems to work. 1. Set up a work directory as described in http://wiki.flightgear.org/index.php/Building_Flightgear_-_Windows. (NOTE: this is now out of date as the 3rdparty , zlib and OSG are all ready to use at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ ) 2. Open the Cmake gui 3. Set “Where is the source code” and “Where to build the binaries” to C:/Flightgear/simgear” (or wherever you have put simgear) 4. Press the “Configure” button. The first time that the project is generated, Cmake will bring up a window asking which compiler you wish to use. Normally just accept Cmakes suggestion, and press Finish. Cmake will now do a check on your system and will produce a preliminary build configuration.´ 5. Check for errors in the red window. Cmake should have found OSG, zlib and your 3rdparty directories. 6. Set CMAKE_INSTALL_PREFIX to C:/Flightgear/install. This is probably not necessary for Windows XP, but is required for Windows 7 as the default (C:\Program Files) is protected. 7. Press “Configure” once more. Errors should all have gone. 8. Press “Generate”. Cmake will now write a windows sln and project files in the simgear directory. 9. Open C:\Flightgear\simgear\simgear.sln. MSVC should come up. Select Release (or debug if you need it) build and then build-all. 10. Once simgear has built successfully (there will be some warnings), build the INSTALL project. This will copy the simgear libraries and include files to C:flightgear\install. 11. Now repeat the Cmake process for flightgear. The directories to choose are C:/Flightgear/flightgear. 12. It is important to chose the same CMAKE_INSTALL_PREFIX, otherwise the simgear libraries will not be found. 13. Open C:\Flightgear\flightgear\flightgear.sln. As with simgear, build all, and then build INSTALL. 14. Flightgear and other executables should be in C:\Flightgear\install\bin. No doubt I have left something out, but this does describe the basic process. Alan From: James Turner Sent: Tuesday, October 18, 2011 9:40 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cmake (soon) _ On 17 Oct 2011, at 18:38, Curtis Olson wrote: Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project. Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions
Re: [Flightgear-devel] Cmake (soon)
On 17 Oct 2011, at 18:38, Curtis Olson wrote: Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project.Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions in a timely manner -- and do that over time if we don't have central place to find this information without investing the required time to become cmake experts ourselves. I'm assuming that's true regardless :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake (soon)
It is about time that such a document was started, many thanks. However windows users will most likely use the CMake gui, which hides all that geeky command line stuff. For Cmake gui the following seems to work. 1. Set up a work directory as described in http://wiki.flightgear.org/index.php/Building_Flightgear_-_Windows. (NOTE: this is now out of date as the 3rdparty , zlib and OSG are all ready to use at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ ) 2. Open the Cmake gui 3. Set “Where is the source code” and “Where to build the binaries” to C:/Flightgear/simgear” (or wherever you have put simgear) 4. Press the “Configure” button. The first time that the project is generated, Cmake will bring up a window asking which compiler you wish to use. Normally just accept Cmakes suggestion, and press Finish. Cmake will now do a check on your system and will produce a preliminary build configuration.´ 5. Check for errors in the red window. Cmake should have found OSG, zlib and your 3rdparty directories. 6. Set CMAKE_INSTALL_PREFIX to C:/Flightgear/install. This is probably not necessary for Windows XP, but is required for Windows 7 as the default (C:\Program Files) is protected. 7. Press “Configure” once more. Errors should all have gone. 8. Press “Generate”. Cmake will now write a windows sln and project files in the simgear directory. 9. Open C:\Flightgear\simgear\simgear.sln. MSVC should come up. Select Release (or debug if you need it) build and then build-all. 10. Once simgear has built successfully (there will be some warnings), build the INSTALL project. This will copy the simgear libraries and include files to C:flightgear\install. 11. Now repeat the Cmake process for flightgear. The directories to choose are C:/Flightgear/flightgear. 12. It is important to chose the same CMAKE_INSTALL_PREFIX, otherwise the simgear libraries will not be found. 13. Open C:\Flightgear\flightgear\flightgear.sln. As with simgear, build all, and then build INSTALL. 14. Flightgear and other executables should be in C:\Flightgear\install\bin. No doubt I have left something out, but this does describe the basic process. Alan From: James Turner Sent: Tuesday, October 18, 2011 9:40 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cmake (soon) _ On 17 Oct 2011, at 18:38, Curtis Olson wrote: Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project.Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions in a timely manner -- and do that over time if we don't have central place to find this information without investing the required time to become cmake experts ourselves. I'm assuming that's true regardless :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake (soon)
Thanks for the instructions, Alan. I tried this twice from scratch—SimGear configures builds just fine, but CMake gets stuck trying to configure FlightGear. I set CMAKE_INSTALL_PREFIX as you said, and building INSTALL seems to have copied SimGear into that directory, but CMake can't find it; any ideas? Git revision is 3rdparty files located in C:/FlightGear apr-1-config not found, implement manual search for APR Could NOT find LIBSVN (missing: LIBSVN_LIBRARIES LIBSVN_INCLUDE_DIR) C:/FlightGear/3rdParty.x64/include adding runtime JS dependencies C:/FlightGear/install/include looking for version: 2.5.0 CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) (Required is at least version 2.5.0) Call Stack (most recent call first): C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE) CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:179 (find_package) Configuring incomplete, errors occurred! cheers, Rob On Tue, Oct 18, 2011 at 09:41, Alan Teeder ajtee...@v-twin.org.uk wrote: It is about time that such a document was started, many thanks. However windows users will most likely use the CMake gui, which hides all that geeky command line stuff. For Cmake gui the following seems to work. 1. Set up a work directory as described in http://wiki.flightgear.org/index.php/Building_Flightgear_-_Windows. (NOTE: this is now out of date as the 3rdparty , zlib and OSG are all ready to use at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ ) 2. Open the Cmake gui 3. Set “Where is the source code” and “Where to build the binaries” to C:/Flightgear/simgear” (or wherever you have put simgear) 4. Press the “Configure” button. The first time that the project is generated, Cmake will bring up a window asking which compiler you wish to use. Normally just accept Cmakes suggestion, and press Finish. Cmake will now do a check on your system and will produce a preliminary build configuration.´ 5. Check for errors in the red window. Cmake should have found OSG, zlib and your 3rdparty directories. 6. Set CMAKE_INSTALL_PREFIX to C:/Flightgear/install. This is probably not necessary for Windows XP, but is required for Windows 7 as the default (C:\Program Files) is protected. 7. Press “Configure” once more. Errors should all have gone. 8. Press “Generate”. Cmake will now write a windows sln and project files in the simgear directory. 9. Open C:\Flightgear\simgear\simgear.sln. MSVC should come up. Select Release (or debug if you need it) build and then build-all. 10. Once simgear has built successfully (there will be some warnings), build the INSTALL project. This will copy the simgear libraries and include files to C:flightgear\install. 11. Now repeat the Cmake process for flightgear. The directories to choose are C:/Flightgear/flightgear. 12. It is important to chose the same CMAKE_INSTALL_PREFIX, otherwise the simgear libraries will not be found. 13. Open C:\Flightgear\flightgear\flightgear.sln. As with simgear, build all, and then build INSTALL. 14. Flightgear and other executables should be in C:\Flightgear\install\bin. No doubt I have left something out, but this does describe the basic process. Alan From: James Turner Sent: Tuesday, October 18, 2011 9:40 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cmake (soon) _ On 17 Oct 2011, at 18:38, Curtis Olson wrote: Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project. Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions in a timely manner -- and do that over time if we don't have central place to find this information without investing the required time to become cmake experts ourselves. I'm assuming that's true regardless :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu
Re: [Flightgear-devel] Cmake (soon)
Hi James, Thanks. I was off line all day test flying our UAS so it looks like I have some serious catch up to do here on several fronts. :-) Curt. On Tue, Oct 18, 2011 at 3:40 AM, James Turner zakal...@mac.com wrote: On 17 Oct 2011, at 18:38, Curtis Olson wrote: Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project.Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions in a timely manner -- and do that over time if we don't have central place to find this information without investing the required time to become cmake experts ourselves. I'm assuming that's true regardless :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake (soon)
Hi James, One thing that stresses me out is large scale technology changes with no documentation or howto's to back them up. This change might be fine for people who are cmake experts. And I know anyone can start from scratch and read the cmake manual from cover to cover. But that takes time and a lot of effort, and there is not enough time in our lives to be experts in everything, but we often need to know some basics in just about every subject. Judging by the number of tweaks and changes I see through the change logs that are cmake config related only, there is a lot of subtle nuance and expertise required to make cmake do the equivalent of autoconf/automake (and the auto tools required a lot of expertise too.) Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project.Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions in a timely manner -- and do that over time if we don't have central place to find this information without investing the required time to become cmake experts ourselves. Thanks! Curt. On Mon, Oct 17, 2011 at 12:10 PM, James Turner wrote: It's been a month since I announced the intention, to switch all the main FG platforms to use CMake, and to deprecate and remove the other build systems from Git. There's been many small improvements in the Cmake files since then, which I hope have eased some people's concerns about the switch. (Notably Brisa' compile scripts have been updated to use Cmake!) I still have some work to do, to ensure the 'make dist' rules are handled property in CMake, so we don't get a shock when releasing FG 2.6 in a few months. Are there are any other issues people have, areas they think should be tested, etc? I'd love to know the status of cygwin and mingw, but only people who run those environments can test or improve them. Barring last minute surprises, my intention is to declare the other build systems 'dead' next weekend (the 21st), and then gradually start disabling Jenkins jobs, removing files, and so on. The idea is to force everyone who runs FG from Git, to definitely be testing and using CMake, in plenty of time for the 2.6 release. Regards, James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake (soon)
Am 17.10.2011 19:10, schrieb James Turner: It's been a month since I announced the intention, to switch all the main FG platforms to use CMake, and to deprecate and remove the other build systems from Git. There's been many small improvements in the Cmake files since then, which I hope have eased some people's concerns about the switch. (Notably Brisa' compile scripts have been updated to use Cmake!) I still have some work to do, to ensure the 'make dist' rules are handled property in CMake, so we don't get a shock when releasing FG 2.6 in a few months. Are there are any other issues people have, areas they think should be tested, etc? I'd love to know the status of cygwin and mingw, but only people who run those environments can test or improve them. Barring last minute surprises, my intention is to declare the other build systems 'dead' next weekend (the 21st), and then gradually start disabling Jenkins jobs, removing files, and so on. The idea is to force everyone who runs FG from Git, to definitely be testing and using CMake, in plenty of time for the 2.6 release. From my perspective, the cmake scripts work well on several Linux distros (Debian, openSUSE and Arch). Go from my side. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi On 11 Sep 2011, at 20:25, Bertrand Coconnier wrote: Have you tried to append your flag with :STRING ? It should look like -D CMAKE_CXX_FLAGS:STRING=-O3 -Wall -march=native. I finally had the time to try this out. Works like a charm. :-) Cheers, Durk -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
I'm uninstall OSG-3.0.1, SG-git and FG-git. Then make fresh folder for each of them, succesfully compile OSG and SG with ~[OSG/SG]/build$ ccmake .. configure, generate, ~[OSG/SG]/build$ make install but FG, with same commands, fails: http://pastebin.com/2V0AL0nY -- --- WBR, Vadym. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Le 12/09/2011 21:31, Stuart Buchanan a écrit : 2011/9/12 Mathias Fröhlich : On Sunday, September 11, 2011 21:29:28 Durk Talsma wrote: My error was in SimGear, and your fix was for FlightGear, it I'm correct. So, I'm not sure if that would fix it. Hmm, then probably not... ... but I have done the same change in the identical file in simgear now. I did not know that there ist also the same one :-/ For me, cmake works fine for SimGear, but I get the following error when attempting to cmake FlightGear: stuart@needle:~/FlightGear/flightgear$ cmake -DCMAKE_BUILD_TYPE=Release . -- Git revision is e47b05e9b459ed564193d6395cfb425148eca26c -- Could NOT find FLTK (missing: FLTK_LIBRARIES FLTK_FLUID_EXECUTABLE) -- libsvn found, enabling in terrasync -- /usr/include -- adding runtime JS dependencies -- /usr/local/include -- looking for version: 2.5.0 -- Include Dir: /usr/local/include CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:218 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:163 (find_package) /usr/local/include/simgear/version.h exists and contains the following: #define SIMGEAR_VERSION 2.5.0 so everything looks OK. I'm sure I'm doing something silly, but can't work out what, and the wiki isn't enlightening. Can anyone tell me what I'm getting wrong? -Stuart Hi, Unfortunately I'm stuck at the same point with no idea on how to solve this one. Here the error with my own paths: alexis@duck:~/fgfs/install/build-flightgear$ cmake -D CMAKE_INSTALL_PREFIX:PATH=/home/alexis/fgfs/install/fgfs -D CMAKE_BUILD_TYPE=Release -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/OpenSceneGraph -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/plib/ -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/simgear /home/alexis/fgfs/flightgear -- Git revision is f2f78e364666fcd11221a7f271de584708c025b7 -- libsvn found, enabling in terrasync -- /home/alexis/fgfs/install/plib/include -- adding runtime JS dependencies -- /home/alexis/fgfs/install/simgear/include -- looking for version: 2.5.0 CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:163 (find_package) -- Configuring incomplete, errors occurred! Thanks for helping on this one. Alexis -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On Sat, Sep 17, 2011 at 6:29 PM, Citronnier - Alexis Bory wrote: Hi, Unfortunately I'm stuck at the same point with no idea on how to solve this one. Here the error with my own paths: snip CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:163 (find_package) -- Configuring incomplete, errors occurred! Thanks for helping on this one. For me, this problem seemed to magically go away a couple of evenings ago after a git pull of simgear, and fresh cmake . / make / make install of simgear. Unfortunately I've no idea what caused or fixed it. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi, I am a bit away from that stuff currently. Currently checking mail in vacation ... But: On Saturday, September 17, 2011 19:29:14 Citronnier - Alexis Bory wrote: alexis@duck:~/fgfs/install/build-flightgear$ cmake -D CMAKE_INSTALL_PREFIX:PATH=/home/alexis/fgfs/install/fgfs -D CMAKE_BUILD_TYPE=Release -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/OpenSceneGraph -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/plib/ -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/simgear /home/alexis/fgfs/flightgear I never use CMAKE_PREFIX_PATH, so I might be wrong, but I assume that setting this value multiple times does not work like expected. Could you try -D CMAKE_PREFIX_PATH=/path/to/osg;/path/to/simgear;... instead of giving this option multiple times? The quotes are probably needed since the ; usually terminates the shell comand. Note that this ; is the list seperator of cmake. Just to better understand this attempt to solve this problem. Greetings Mathias -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Durk, On Sunday, September 11, 2011 21:29:28 Durk Talsma wrote: My error was in SimGear, and your fix was for FlightGear, it I'm correct. So, I'm not sure if that would fix it. Hmm, then probably not... ... but I have done the same change in the identical file in simgear now. I did not know that there ist also the same one :-/ Greetings Mathias -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
why not use: qmake? as described here: http://forums.x-plane.org/index.php?showtopic=48012 From: Mathias Fröhlich mathias.froehl...@gmx.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Monday, September 12, 2011 8:25 AM Subject: Re: [Flightgear-devel] Cmake Hi Durk, On Sunday, September 11, 2011 21:29:28 Durk Talsma wrote: My error was in SimGear, and your fix was for FlightGear, it I'm correct. So, I'm not sure if that would fix it. Hmm, then probably not... ... but I have done the same change in the identical file in simgear now. I did not know that there ist also the same one :-/ Greetings Mathias -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel-- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
2011/9/12 Mathias Fröhlich : On Sunday, September 11, 2011 21:29:28 Durk Talsma wrote: My error was in SimGear, and your fix was for FlightGear, it I'm correct. So, I'm not sure if that would fix it. Hmm, then probably not... ... but I have done the same change in the identical file in simgear now. I did not know that there ist also the same one :-/ For me, cmake works fine for SimGear, but I get the following error when attempting to cmake FlightGear: stuart@needle:~/FlightGear/flightgear$ cmake -DCMAKE_BUILD_TYPE=Release . -- Git revision is e47b05e9b459ed564193d6395cfb425148eca26c -- Could NOT find FLTK (missing: FLTK_LIBRARIES FLTK_FLUID_EXECUTABLE) -- libsvn found, enabling in terrasync -- /usr/include -- adding runtime JS dependencies -- /usr/local/include -- looking for version: 2.5.0 -- Include Dir: /usr/local/include CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:218 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:163 (find_package) /usr/local/include/simgear/version.h exists and contains the following: #define SIMGEAR_VERSION 2.5.0 so everything looks OK. I'm sure I'm doing something silly, but can't work out what, and the wiki isn't enlightening. Can anyone tell me what I'm getting wrong? -Stuart -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Mathias, On 10 Sep 2011, at 10:57, Mathias Fröhlich wrote: Hi, Ok, then it's probably best to deinstall the distros cmake and install cmake from sources. Or may be cmake has some binary distributions that fits your needs. Thanks for your suggestion (and to Fred as well). All things considered, I decided that it would be time to bite the bullet and to a full system upgrade from opensuse 10.0 to 11.4. The upgrade is proceeding smoothly, and I'm currently compiling OpenSceneGraph SVC/trunk. I hope that FlightGear will behave nicely with the xinerama xserver configuration, because I'm running kde4, which apparently doesn't like multiple monitor configurations that much (last time I checked there were some performance / stability issues, but that was 3 years ago...). I'm also taking this opportunity to try out a few new things. A couple of years ago I had already switched from emacs to kdevelop for editing, but now with cmake, it looks like it's also very easy to generate kdevelop compatible project files. Maybe that was already possible with autoconf, but I never really tried it. Cheers, Durk -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hello,
Am 11.09.2011 09:57, schrieb Durk Talsma:
[..] I hope that FlightGear will behave nicely with the
xinerama xserver configuration, because I'm running kde4, which
apparently doesn't like multiple monitor configurations that much
I'm using a double monitor setup here with 11.4/KDE4 configured via
xrandr without any problems, so that looks stable by now.
I'm also taking this opportunity to try out a few new things. A
couple of years ago I had already switched from emacs to kdevelop for
editing, but now with cmake, it looks like it's also very easy to
generate kdevelop compatible project files. Maybe that was already
possible with autoconf, but I never really tried it.
one problem I noticed with that is that the headers aren't added to the
project in SimGear. At least Codeblocks is not able to add them
automatically parsing the includes, so the attached patch does that
explicitly. This allows things like jump to definition also for
header-only classes, which up to now produces errors. Apart from that,
I'm doing fairly well with the generated CB projects. Haven't tried
kdevelop, though.
While we're at it, FindOpenSceneGraph.cmake claims it was added in CMake
2.6.3, while SimGear's CMakeList only has cmake_minimum_required(VERSION
2.6) , so this should be updated (maybe directly to 2.8?).
Yet another thing: when trying to build with CMAKE_BUILD_TYPE
RelWithDebInfo or MinSizeRel, the FlightGear build will fail unless you
have SimGear libraries in Release configuration still around (against
which it will link, but not against the matching configuration). This is
because SelectLibraryConfigurations.cmake only knows about Debug and
Release. Fixing this might however be a bit tricky, and I don't know how
many people are actually going to use these build types. Maybe a warning
about an unsupported build type is sufficient. As a fallback it is
always possible to alter CMAKE_CXX_FLAGS directly.
Best regards,
Andreas
commit 8334007d6a1f7b9831fd1fd8813dc6752f042c10
Author: Andreas Gaeb a.g...@web.de
Date: Fri Sep 9 21:28:37 2011 +0200
Add headers to library components
so that they get included into the IDE project files
diff --git a/CMakeModules/SimGearComponent.cmake b/CMakeModules/SimGearComponent.cmake
index 3eb5740..7dbf5f1 100644
--- a/CMakeModules/SimGearComponent.cmake
+++ b/CMakeModules/SimGearComponent.cmake
@@ -14,7 +14,7 @@ macro(simgear_component name includePath sources headers)
else()
set(libName sg${name})
-add_library(${libName} STATIC ${sources} )
+add_library(${libName} STATIC ${sources} ${headers})
install (TARGETS ${libName} ARCHIVE DESTINATION lib${LIB_SUFFIX})
install (FILES ${headers} DESTINATION include/simgear/${includePath})
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Christian Schmitt wrote: I have used CMake in the Gentoo packages pretty much from the start, but right now I'm experiencing some problems: all is good as long as I have libsvn support enabled in SG and FG. When I disable it in SG and want to recompile FG afterwards (also disabled, of course), I get a linking error for Terrasync: This is now solved with the latest FG git version. Thanks! -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi, On Sunday, September 11, 2011 12:55:33 Christian Schmitt wrote: This is now solved with the latest FG git version. Thanks! Ok, thanks, I was on the way asking for that :) Mathias -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Andreas, On 11 Sep 2011, at 12:18, Andreas Gaeb wrote: one problem I noticed with that is that the headers aren't added to the project in SimGear. At least Codeblocks is not able to add them automatically parsing the includes, so the attached patch does that explicitly. This allows things like jump to definition also for header-only classes, which up to now produces errors. Apart from that, I'm doing fairly well with the generated CB projects. Haven't tried kdevelop, though. Thanks for sharing your experiences. After having played with the new kdevelop, my first impression is leaning toward the positive side, but not completely positive. I like the enhanced editing, and online syntax checking. Particularly, the context sensitve list of suggested completions is really handy. But, some other options, like the kdevelop definition of a current project selection is slightly awkward, and I also found that the integrated cmake is slightly awkward when you choose a build location other than the default. But, given that I have been learning as I went, it's probable that I left a trail of garbage behind. So, I might restart from scratch and take it from there. While we're at it, FindOpenSceneGraph.cmake claims it was added in CMake 2.6.3, while SimGear's CMakeList only has cmake_minimum_required(VERSION 2.6) , so this should be updated (maybe directly to 2.8?). I thought that Fred mentioned on the mailing list the we only officially support cmake 2.8.0 and higher. Yet another thing: when trying to build with CMAKE_BUILD_TYPE RelWithDebInfo or MinSizeRel, the FlightGear build will fail unless you have SimGear libraries in Release configuration still around (against which it will link, but not against the matching configuration). This is because SelectLibraryConfigurations.cmake only knows about Debug and Release. Fixing this might however be a bit tricky, and I don't know how many people are actually going to use these build types. Maybe a warning about an unsupported build type is sufficient. As a fallback it is always possible to alter CMAKE_CXX_FLAGS directly. Which actually brings me to the next question: I'm currently trying to build a heavily optimized version of FlightGear, and want to pass a number of options cmake. I got the basic mechanism to work; i.e. -D CMAKE_CXX_FLAGS=-O3 -Wall. But, in my autoconf based compile script, I pass an option containing an equals character (i.e. =_). When I try to pass that to cmake, using for example: -D CMAKE_CXX_FLAGS=-O3 -Wall -march=native, if found that the entire token containing the = character, as well as all the tokens following it, are ignored. I've tried most of the known unix tricks to escape the = character, but to no avail. Any ideas? Cheers, Durk -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
2011/9/11 Durk Talsma durkt...@gmail.com: Which actually brings me to the next question: I'm currently trying to build a heavily optimized version of FlightGear, and want to pass a number of options cmake. I got the basic mechanism to work; i.e. -D CMAKE_CXX_FLAGS=-O3 -Wall. But, in my autoconf based compile script, I pass an option containing an equals character (i.e. =_). When I try to pass that to cmake, using for example: -D CMAKE_CXX_FLAGS=-O3 -Wall -march=native, if found that the entire token containing the = character, as well as all the tokens following it, are ignored. I've tried most of the known unix tricks to escape the = character, but to no avail. Any ideas? Cheers, Durk Have you tried to append your flag with :STRING ? It should look like -D CMAKE_CXX_FLAGS:STRING=-O3 -Wall -march=native. Cheers, Bertrand. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On 11 Sep 2011, at 20:25, Bertrand Coconnier wrote: Have you tried to append your flag with :STRING ? It should look like -D CMAKE_CXX_FLAGS:STRING=-O3 -Wall -march=native. Not yet, but I'll certainly give it a try. Thanks! Cheers, Durk -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On 11 Sep 2011, at 13:18, Mathias Fröhlich wrote: Hi, On Sunday, September 11, 2011 12:15:42 Durk Talsma wrote: -- Configuring incomplete, errors occurred! I don't get that hard error, but I have checked in something that fixes similar symptoms. So, could you retry? Hi Mathias, My error was in SimGear, and your fix was for FlightGear, it I'm correct. So, I'm not sure if that would fix it. Cheers, Durk -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On Monday 05 September 2011 10:10:27 Curtis Olson wrote: Are there any cmake based build instructions available anywhere? I'm not seeing them. I'm just hoping the cmake jocks will put themselves in the position of non-cmake jocks and help ease the transition from multiple fronts for many of our different classes of users/developers. Thanks! Curt. Let me echo what Curt said. I don't like CMake that much, because it seems overly complicated. HOW DO I BUILD FLIGHTGEAR NOW? Thank you, Ron -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
If you regularly pull+build 'next', please try a cmake based build, and
report any issues you encounter - CMake should work 'out of the box' on Mac
(Makefiles or XCode), Linux (32- and 64- bit) and Windows (VisualStudio 2008
and 2010 - mingw and cygwin may need some fixes).
Hi James,
I'm trying to build a Cmake build on linux, and I'm running into the following
problem:
CMake Error at CMakeLists.txt:76 (find_package):
Could not find module FindOpenSceneGraph.cmake or a configuration file for
package OpenSceneGraph.
Adjust CMAKE_MODULE_PATH to find FindOpenSceneGraph.cmake or set
OpenSceneGraph_DIR to the directory containing a CMake configuration file
for OpenSceneGraph. The file will have one of the following names:
OpenSceneGraphConfig.cmake
openscenegraph-config.cmake
Looking at simgear/CMakeModules, I do see a FindSvnClient.cmake, but no
FindOpenSceneGraph.cmake. Is there any chance this file hasn't been committed
to git yet?
FWIW, I have my source tree organized as:
${HOME}/src/OpenSceneGraph*
${HOME}/src/flightgear-git/simgear
${HOME}/src/flightgear-git/simgear-build
${HOME}/src/flightgear-git/simgear-cmake
${HOME}/src/flightgear-git/flightgear
${HOME}/src/flightgear-git/flightgear-build
${HOME}/src/flightgear-git/flightgear-cmake
${HOME}/src/fgdata
(Where OpenSceneGraph* refers to a number of separate directories:
OpenSceneGraph for SVN/trunk, OpenSceneGraph-2.8.1, and OpenSceneGraph-2.9.11)
Cheers,
Durk
--
Malware Security Report: Protecting Your Business, Customers, and the
Bottom Line. Protect your business and customers by understanding the
threat from malware and how it can impact your online business.
http://www.accelacomm.com/jaw/sfnl/114/51427462/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Durk,
- Mail original -
If you regularly pull+build 'next', please try a cmake based build,
and report any issues you encounter - CMake should work 'out of
the box' on Mac (Makefiles or XCode), Linux (32- and 64- bit) and
Windows (VisualStudio 2008 and 2010 - mingw and cygwin may need
some fixes).
Hi James,
I'm trying to build a Cmake build on linux, and I'm running into the
following problem:
CMake Error at CMakeLists.txt:76 (find_package):
Could not find module FindOpenSceneGraph.cmake or a configuration
file for
package OpenSceneGraph.
Adjust CMAKE_MODULE_PATH to find FindOpenSceneGraph.cmake or set
OpenSceneGraph_DIR to the directory containing a CMake
configuration file
for OpenSceneGraph. The file will have one of the following
names:
OpenSceneGraphConfig.cmake
openscenegraph-config.cmake
Looking at simgear/CMakeModules, I do see a FindSvnClient.cmake, but
no FindOpenSceneGraph.cmake. Is there any chance this file hasn't
been committed to git yet?
FWIW, I have my source tree organized as:
${HOME}/src/OpenSceneGraph*
${HOME}/src/flightgear-git/simgear
${HOME}/src/flightgear-git/simgear-build
${HOME}/src/flightgear-git/simgear-cmake
${HOME}/src/flightgear-git/flightgear
${HOME}/src/flightgear-git/flightgear-build
${HOME}/src/flightgear-git/flightgear-cmake
${HOME}/src/fgdata
(Where OpenSceneGraph* refers to a number of separate directories:
OpenSceneGraph for SVN/trunk, OpenSceneGraph-2.8.1, and
OpenSceneGraph-2.9.11)
FindOpenSceneGraph.cmake is in the Cmake distribution, in the share directory.
You certainly need to tell Cmake where the installed OSG is.
Regards,
-Fred
--
Malware Security Report: Protecting Your Business, Customers, and the
Bottom Line. Protect your business and customers by understanding the
threat from malware and how it can impact your online business.
http://www.accelacomm.com/jaw/sfnl/114/51427462/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
hi Fred, On 10 Sep 2011, at 10:28, Frederic Bouvier wrote: Hi Durk, FindOpenSceneGraph.cmake is in the Cmake distribution, in the share directory. You certainly need to tell Cmake where the installed OSG is. Regards, -Fred Thanks; looking at /usr/share/cmake/Modules, I see that I have a Findosg.cmake file, as well as several Findosg*.cmake files, but no FindOpenSceneGraph.cmake. FWIW, this is one an opensuse 10.0, running cmake version 2.6 - patch 2 Just double checking on my laptop, I do note that cmake 2.8.3 does work as advertised. Is there any way to get this to work on older distributions? I probably need to upgrade my 3 yr. old distro anyhow, because yesterday I also ran into a git error, which would require an upgrade. But, it's not something I'm really looking forward doing right now... Cheers, Durk -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
- Mail original - hi Fred, On 10 Sep 2011, at 10:28, Frederic Bouvier wrote: Hi Durk, FindOpenSceneGraph.cmake is in the Cmake distribution, in the share directory. You certainly need to tell Cmake where the installed OSG is. Regards, -Fred Thanks; looking at /usr/share/cmake/Modules, I see that I have a Findosg.cmake file, as well as several Findosg*.cmake files, but no FindOpenSceneGraph.cmake. FWIW, this is one an opensuse 10.0, running cmake version 2.6 - patch 2 Just double checking on my laptop, I do note that cmake 2.8.3 does work as advertised. Is there any way to get this to work on older distributions? I probably need to upgrade my 3 yr. old distro anyhow, because yesterday I also ran into a git error, which would require an upgrade. But, it's not something I'm really looking forward doing right now... We are using Cmake 2.8 -Fred -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi Durk, On Saturday, September 10, 2011 10:28:22 Frederic Bouvier wrote: FindOpenSceneGraph.cmake is in the Cmake distribution, in the share directory. You certainly need to tell Cmake where the installed OSG is. Correct, this should be cmake provided. So, cmake does not find its own files. How and where did you install cmake? Greetings Mathias -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi, On Saturday, September 10, 2011 10:46:03 Durk Talsma wrote: Thanks; looking at /usr/share/cmake/Modules, I see that I have a Findosg.cmake file, as well as several Findosg*.cmake files, but no FindOpenSceneGraph.cmake. FWIW, this is one an opensuse 10.0, running cmake version 2.6 - patch 2 Just double checking on my laptop, I do note that cmake 2.8.3 does work as advertised. Is there any way to get this to work on older distributions? I probably need to upgrade my 3 yr. old distro anyhow, because yesterday I also ran into a git error, which would require an upgrade. But, it's not something I'm really looking forward doing right now... Ok, then it's probably best to deinstall the distros cmake and install cmake from sources. Or may be cmake has some binary distributions that fits your needs. Greetings Mathias -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
James Turner wrote: If you regularly pull+build 'next', please try a cmake based build, and report any issues you encounter - CMake should work 'out of the box' on Mac (Makefiles or XCode), Linux (32- and 64- bit) and Windows (VisualStudio 2008 and 2010 - mingw and cygwin may need some fixes). I have used CMake in the Gentoo packages pretty much from the start, but right now I'm experiencing some problems: all is good as long as I have libsvn support enabled in SG and FG. When I disable it in SG and want to recompile FG afterwards (also disabled, of course), I get a linking error for Terrasync: Linking CXX executable terrasync [ 47%] Building CXX object src/FDM/CMakeFiles/fgFDM.dir/UIUCModel/uiuc_auto_pilot.cpp.o /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::~SGThread()': (.text+0x41): undefined reference to `pthread_detach' /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::start()': (.text+0xce): undefined reference to `pthread_create' /usr/lib/gcc/x86_64-pc-linux- gnu/4.5.3/../../../../lib64/libsgthreads.a(SGThread.cxx.o): In function `SGThread::join()': (.text+0x116): undefined reference to `pthread_join' collect2: ld returned 1 exit status make[2]: *** [utils/TerraSync/terrasync] Error 1 make[1]: *** [utils/TerraSync/CMakeFiles/terrasync.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs I don't know if this is caused by the recent cmake changes or rather by the threads class rewrite... HTH Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Please don´t. I reverted from VC100 to VC90 as the Cmake process was always failing. There is a difference between Hudson saying that all is OK with Cmake and Visual Studio VC100 producing working executables. This was all with the de-facto standard 3rd party package from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/. I could get the system to work, but then it would all go wrong after a few days or weeks. On the other hand the current VC90 project files seem quite robust. Just my experience. Alan -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi, On Monday, September 05, 2011 14:47:44 Alan Teeder wrote: Please don´t. I reverted from VC100 to VC90 as the Cmake process was always failing. There is a difference between Hudson saying that all is OK with Cmake and Visual Studio VC100 producing working executables. This was all with the de-facto standard 3rd party package from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/. I could get the system to work, but then it would all go wrong after a few days or weeks. On the other hand the current VC90 project files seem quite robust. Then please tell what is going wrong. This is like every piece of code lingering around in this and similar projects. The people doing the changes do their best to make it work. But if there is something failing on some other platform/configuration/... feedback is needed. Thanks Mathias -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
So I have nothing against cmake, it sounds like it offers some nice features. But I assume those that want to push this change forward, will take some time to write up some basic howto's so that people who have never used it as a developer can get up to speed without too many problems? Right now when I poke around on the wiki and I'm sure the getstart manual, all the instructions are automake based. Hopefully we can do some proactive hunting of automake references in our instructions scattered around and get those cleaned up in advance? Are there any cmake based build instructions available anywhere? I'm not seeing them. When building OSG, you run ./configure; make; make install like any other project. However, ./configure is an automake/conf generated in flightgear. For a cmake dummy, how do you even go about building flightgear with cmake? (I of course know everything, but I do have a friend who's a little inexperienced with cmake.) Is there a way to do the equivalent of make dist in cmake to generate .tar.gz source releases? Has this been tested to see if it includes all the necessary files? We have some extra automake rules to help create the data archives (which is important because this officially defines what goes into the release installer for both Mac and Windows as well as the data archive for people building from source code (who aren't doing 3Gb of git for the data tree.)) I'm just hoping the cmake jocks will put themselves in the position of non-cmake jocks and help ease the transition from multiple fronts for many of our different classes of users/developers. Thanks! Curt. 2011/9/5 Mathias Fröhlich mathias.froehl...@gmx.net Hi, On Monday, September 05, 2011 14:47:44 Alan Teeder wrote: Please don´t. I reverted from VC100 to VC90 as the Cmake process was always failing. There is a difference between Hudson saying that all is OK with Cmake and Visual Studio VC100 producing working executables. This was all with the de-facto standard 3rd party package from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/. I could get the system to work, but then it would all go wrong after a few days or weeks. On the other hand the current VC90 project files seem quite robust. Then please tell what is going wrong. This is like every piece of code lingering around in this and similar projects. The people doing the changes do their best to make it work. But if there is something failing on some other platform/configuration/... feedback is needed. Thanks Mathias -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Curtis Olson wrote: I'm just hoping the cmake jocks will put themselves in the position of non-cmake jocks and help ease the transition from multiple fronts for many of our different classes of users/developers. With CMake there's a list of flags you're appending to the 'cmake' call similarly to calling 'configure' with custom flags - and with no flags at all it'll create a default build for you depending on the prerequisites installed on your system. Thus, there's nothing terribly different from Automake except from the fact that you will _always_ have to append the source directory for CMake - which will be a simple trailing dot for in-tree-builds ;-) Rest assured that work to bring the CMake build system for SimGear and FlightGear onto the same level as the former build systems is already in progress. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Is there support for the --prefix= concept of autoconf? I really struggled to find anything like that in OSG's cmake config and it appeared I would be forced to define a really ugly/long list of environment variables before running make install in order to accomplish a similar thing (installing somewhere other than /usr/local/ or using an installation somewhere outside of /usr/local/ In the end I just gave my hope to manage a couple different versions of osg, and just wrote over my older version with the newer version. Thanks, Curt. On Mon, Sep 5, 2011 at 11:25 AM, Martin Spott wrote: Curtis Olson wrote: I'm just hoping the cmake jocks will put themselves in the position of non-cmake jocks and help ease the transition from multiple fronts for many of our different classes of users/developers. With CMake there's a list of flags you're appending to the 'cmake' call similarly to calling 'configure' with custom flags - and with no flags at all it'll create a default build for you depending on the prerequisites installed on your system. Thus, there's nothing terribly different from Automake except from the fact that you will _always_ have to append the source directory for CMake - which will be a simple trailing dot for in-tree-builds ;-) Rest assured that work to bring the CMake build system for SimGear and FlightGear onto the same level as the former build systems is already in progress. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Is this an option to cmake at the configure step, or to make at the
build/install step? Can this work as an environment variable? What if I
want to pick up build libraries from a non-standard location ... maybe I'd
like to install a particular version of FG and a particular version of all
it's prerequisites somewhere strange like /opt/FlightGear-2.4/ so everything
it needs is self contained there and I can have other versions of the
prerequisites elsewhere?
The automake --prefix= option was sort of an all in one thing. It not only
added this to the *front* of the include and library search path for
compiling, but it also defined the install paths such as $prefix/lib,
$prefix/include, $prefix/bin, etc. where everything would be placed when
make install is run.
Thanks,
Curt.
On Mon, Sep 5, 2011 at 11:37 AM, Martin Spott martin.sp...@mgras.netwrote:
Curtis Olson wrote:
Is there support for the --prefix= concept of autoconf?
-D CMAKE_INSTALL_PREFIX=${FG_HOME}
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
-Original Message- From: MathiasFröhlich Sent: Monday, September 05, 2011 4:28 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cmake Hi, On Monday, September 05, 2011 14:47:44 Alan Teeder wrote: Please don´t. I reverted from VC100 to VC90 as the Cmake process was always failing. There is a difference between Hudson saying that all is OK with Cmake and Visual Studio VC100 producing working executables. This was all with the de-facto standard 3rd party package from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/. I could get the system to work, but then it would all go wrong after a few days or weeks. On the other hand the current VC90 project files seem quite robust. Then please tell what is going wrong. This is like every piece of code lingering around in this and similar projects. The people doing the changes do their best to make it work. But if there is something failing on some other platform/configuration/... feedback is needed. Thanks Mathias --- Mathias I did, but I am afraid that your reply did not address my question. When I did get it working, every time that there was a change requiring a new set of project files, Cmake got very confused and came up with new sets of problems. Each time that I deleted the cache (to start afresh when cmake gave up), cmake wanted loads of info, most of which it should have known as my flightgear folder layout is the standard one. Boringly, I had to re-enter the location of every simgear library, as well as openal and zlib which already existed in the 3rd party structure. A few more hiccups, which I can no longer remember, VS produced an executable However this would not run and usually involved using the depends tool to work out why FG had been made with the wrong set of libraries. The final straw came with the incorporation of HLA, which I never sorted out. VC100 is to be avoided like the plague. It even seems to have problems linking with libraries produced with different versions of VC100. Alan -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Curtis Olson wrote:
Is this an option to cmake at the configure step, or to make at the
build/install step?
The install prefix is set at the configure step - CMake is quite
similar to Autoconf in this respect. To put an example, configuring
SimGear on a setup with TerraSync/SVN explicitly disabled would look
like this:
# ${SRC}/simgear cmake -D CMAKE_INSTALL_PREFIX=${FG_HOME} -D
ENABLE_LIBSVN=OFF .
# ${SRC}/simgear make
# ${SRC}/simgear make install
Additional flags are optional, similarly to Automake.
[...] What if I
want to pick up build libraries from a non-standard location ... maybe I'd
like to install a particular version of FG and a particular version of all
it's prerequisites somewhere strange like /opt/FlightGear-2.4/ so everything
it needs is self contained there and I can have other versions of the
prerequisites elsewhere?
CMake in FlightGear does exactly this. configure eeeh, cmake
with -D CMAKE_INSTALL_PREFIX=${FG_HOME} and it'll find SimGear in
exactly this place. At least it's working this way for me and we'll
try to make sure it will work on other people's setups the same way -
if it doesn't already do so. Custom flags to find custom
pre-requisites in custom places are being applied in a familiar manner
(like -D RTI_LIBRARY=/opt/OpenRTI/lib/libRTI-NG.so for example).
There are six weeks left until we're caught by the Automake deadline,
two more months until feature freeze plus another two months until
release. I'm pretty certain that's sufficient time to get the pending
issues ironed out until release - at least for those setups whose
maintainers are seriously interested in having a working build.
Well, you'll never catch 100 % of the help me, my build is broken -
but I won't tell you, how 's - that's life ;-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On 5 Sep 2011, at 17:10, Curtis Olson wrote: So I have nothing against cmake, it sounds like it offers some nice features. But I assume those that want to push this change forward, will take some time to write up some basic howto's so that people who have never used it as a developer can get up to speed without too many problems? Right now when I poke around on the wiki and I'm sure the getstart manual, all the instructions are automake based. Hopefully we can do some proactive hunting of automake references in our instructions scattered around and get those cleaned up in advance? Are there any cmake based build instructions available anywhere? I'm not seeing them. Yes, absolutely - Brisa's helper script also needs to be updated. We're at the start of that process now, but I don't want to document things if they are about to change, which brings me too: When building OSG, you run ./configure; make; make install like any other project. However, ./configure is an automake/conf generated in flightgear. For a cmake dummy, how do you even go about building flightgear with cmake? (I of course know everything, but I do have a friend who's a little inexperienced with cmake.) OSG supply a 'configure' script for sue with Cmake, and we can do the same, to keep things more familiar for people. I'll look into borrowing the CMake one :) Is there a way to do the equivalent of make dist in cmake to generate .tar.gz source releases? Has this been tested to see if it includes all the necessary files? That's what CPack does - I've tested tar.gz creation, and there is some supported for Slackware TGZ / .deb / .rpm creation too. I'm sure the rules need some improvement to catch all the docs / utils / data files that the current make dist captures. We have some extra automake rules to help create the data archives (which is important because this officially defines what goes into the release installer for both Mac and Windows as well as the data archive for people building from source code (who aren't doing 3Gb of git for the data tree.)) Indeed! I'm just hoping the cmake jocks will put themselves in the position of non-cmake jocks and help ease the transition from multiple fronts for many of our different classes of users/developers. Yes absolutely, and feedback (like above) is the driver for that. james -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake + VC2010 link errors
Allan I know nothing about building on windows, but I have found installing osg multiple times on linux can cause issues as it does not always un-install cleanly, and the next install may not overwrite what is left behind. All is nice till you try and compile against it. Especially if its a different version. It had it leave sym links and stuff behind, which fouls thing up when you install a different version. Just check you have not got anything left from previous installs. Maybe you need to remove osg and make sure its clean then reinstall it. I guess it has a log of there it puts things? Others will know more about it from your printout it than I, but its worth a check. Harry On Sat, Feb 12, 2011 at 6:28 PM, Alan Teeder ajtee...@v-twin.org.uk wrote: After many rebuilds of OSG, Simgear and Flightgear with the Cmake system I am still seeing a few warnings and errors at link time. Does anyone have any ideas please? TIA Alan -- Build started: Project: fgfs, Configuration: Release Win32 -- osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: void __thiscall std::basic_ifstreamchar,struct std::char_traitschar ::`vbase destructor'(void) (??_D?$basic_ifstream@DU?$char_traits@D@std@@@std@@QAEXXZ) already defined in fgATCDCL.lib(ATCVoice.obj); second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: void __thiscall std::basic_ifstreamchar,struct std::char_traitschar ::close(void) (?close@?$basic_ifstream@DU?$char_traits@D@std@@@std@@QAEXXZ) already defined in fgATCDCL.lib(ATCVoice.obj); second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: __thiscall std::basic_ifstreamchar,struct std::char_traitschar ::basic_ifstreamchar,struct std::char_traitschar (char const *,int,int) (??0?$basic_ifstream@DU?$char_traits@D@std@@@std@@QAE@PBDHH@Z) already defined in fgInstruments.lib(HUD.obj); second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: void __thiscall std::basic_ofstreamchar,struct std::char_traitschar ::`vbase destructor'(void) (??_D?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAEXXZ) already defined in logger.obj; second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: void __thiscall std::basic_ofstreamchar,struct std::char_traitschar ::close(void) (?close@?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAEXXZ) already defined in fgTraffic.lib(TrafficMgr.obj); second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: __thiscall std::basic_ofstreamchar,struct std::char_traitschar ::basic_ofstreamchar,struct std::char_traitschar (char const *,int,int) (??0?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAE@PBDHH@Z) already defined in logger.obj; second definition ignored Creating library C:/FlightGear/flightgear/src/Main/Release/fgfs.lib and object C:/FlightGear/flightgear/src/Main/Release/fgfs.exp sgmodel.lib(animation.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@@Z) referenced in function public: __thiscall std::basic_ostreamchar,struct std::char_traitschar ::sentry::~sentry(void) (??1sentry@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAE@XZ) sgmodel.lib(SGReaderWriterXML.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@@Z) sgtgdb.lib(obj.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@@Z) sgmodel.lib(particles.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@@Z) sgmodel.lib(modellib.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@@Z) sgmodel.lib(ModelRegistry.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class
Re: [Flightgear-devel] Cmake + VC2010 link errors
Hi Allan, this issue has been discussed on the osg ML and is likely a bug in VS2010. These warnings are the best we can do. By default, these are errors, but the cmake configure script adds /FORCE:MULTIPLE to allow multiply defined symbols in an executable. Regards, -Fred - Alan Teeder a écrit : After many rebuilds of OSG, Simgear and Flightgear with the Cmake system I am still seeing a few warnings and errors at link time. Does anyone have any ideas please? TIA Alan -- Build started: Project: fgfs, Configuration: Release Win32 -- osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: void __thiscall std::basic_ifstreamchar,struct std::char_traitschar ::`vbase destructor'(void) (??_D?$basic_ifstream@DU?$char_traits@D@std@@@std@@QAEXXZ) already defined in fgATCDCL.lib(ATCVoice.obj); second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: void __thiscall std::basic_ifstreamchar,struct std::char_traitschar ::close(void) (?close@?$basic_ifstream@DU?$char_traits@D@std@@@std@@QAEXXZ) already defined in fgATCDCL.lib(ATCVoice.obj); second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: __thiscall std::basic_ifstreamchar,struct std::char_traitschar ::basic_ifstreamchar,struct std::char_traitschar (char const *,int,int) (??0?$basic_ifstream@DU?$char_traits@D@std@@@std@@QAE@PBDHH@Z) already defined in fgInstruments.lib(HUD.obj); second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: void __thiscall std::basic_ofstreamchar,struct std::char_traitschar ::`vbase destructor'(void) (??_D?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAEXXZ) already defined in logger.obj; second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: void __thiscall std::basic_ofstreamchar,struct std::char_traitschar ::close(void) (?close@?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAEXXZ) already defined in fgTraffic.lib(TrafficMgr.obj); second definition ignored osgDB.lib(osg69-osgDB.dll) : warning LNK4006: public: __thiscall std::basic_ofstreamchar,struct std::char_traitschar ::basic_ofstreamchar,struct std::char_traitschar (char const *,int,int) (??0?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAE@PBDHH@Z) already defined in logger.obj; second definition ignored Creating library C:/FlightGear/flightgear/src/Main/Release/fgfs.lib and object C:/FlightGear/flightgear/src/Main/Release/fgfs.exp sgmodel.lib(animation.obj) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function public: __thiscall std::basic_ostreamchar,struct std::char_traitschar ::sentry::~sentry(void) (??1sentry@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAE@XZ) sgmodel.lib(SGReaderWriterXML.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) sgtgdb.lib(obj.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) sgmodel.lib(particles.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) sgmodel.lib(modellib.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) sgmodel.lib(ModelRegistry.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (__imp_?setName@Object@osg@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) sgsky.lib(cloud.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) public: void __thiscall osg::Object::setName(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const )
