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
