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 OSG<name>_LIBRARY_DEBUG and OSG<name>_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 directory sections, all these 96 things are filled in for me ;=)) But if I wanted to use a simgear or plib outside this '3rdparty' idea, then I would have to manually complete each of these 96 configurations ;=(( So it is certainly a case of CONFORM to what we say, recommend, or you will face a big finger crunching task ;=)) And sorry, my earlier estimate of 384 configuration items, turns out to only be about 197 configurations item - I used a quick perl script for the first estimate, and it looks like I double counted each item ;=((! And I only had to MANUALLY set about 30 of those... As indicated previously, you can see an image of it all at :- http://geoffair.org/fg/fgfs-055.htm#img_fg But this time I did NOT get the 'WARNINGS' shown in that image, so must have done something better ;=)) So again, this test was using the DEFAULT shared libraries, but I do NOT see yet how to reduce this 30 manual settings... And it is only 30 because I am conforming 100% to the MANDATORY directory structuring... I have NOT yet tried the generated MSVC build files, but eyeballing say the Main fgfs.vcproj, I see it has one of the longest AdditionalDependencies="..." lines I have ever seen - some 2700 characters long... The important thing is that it seems to contain all the OSG(8), PLIB(7) and SimGear(25) libraries, correctly separated for Release and Debug (+d or +_d in PLIB case), plus winmm.lib added twice ;=)) And as mentioned some time back, I do note it FAILED to use zlibd.lib for the Debug build - using just zlib.lib for both ;=(( I will tomorrow, or soon after trash all this again, and go back to what I want, and that is the static OSG library use, and I do not expect this number of manual interventions to change radically... And will be prepared to eat my hat if that is not true ;=)) That is not a big promise in my case since I do not wear or even own a hat ;=)))) And no, I do not statically link against msvcrt, but against LIBCMT and LIBCMTD, the 'static' forms of MSVCRT... and these forms can NOT be mixed... And I have not yet had time to see if pthreads-win32 can now be left out of the windows mix completely - I hope so ;=)) In a quick grep search of SG/FG did see a few includes of <pthread.h>, but MAYBE these are all in #ifndef _MSC_VER, or some other conditional macro excluding windows... You asked a lot of questions about the windows simgear cmake... well I have forgotten how many actual manual steps were involved there... But in general all 25x2 libraries built fine, as did some 14x2 other EXE programs... so it found OSG and other dependents fine... of course the x2 just means Debug and Release configurations... The cmake build also offers an additional two more configurations - which I did not try to build, but would expect no problems. That is - MinSizeRel - Uses /O1 instead of Release /O2 RelWithDebInfo - Is Rel with /Zi This latter might be interesting for debugging but have still to experiment with it. The full debug build is with /Od /Zi, and runs incredibly slow in that every function has an enhanced function preamble, filling all stack variables with a pattern, and stack checking on functions exit, as well as all memory allocation are extended in size, and filled with a head and tail pattern to detect under and overrun of all allocation... all of which costs big time... Later, I will go back and re-do SG, and record better what was the minimal number of manual steps... And to see if I can work out a way to tell it to 'install' into the '3rdparty' folder... On the first run, I did this 'install' manually, but there should be a way... remember we do not have or use 'make install' in windows... there is an INSTALL.vcproj, but so far I can not make it do anything... Anyway, from my perspective, things ARE moving forward, and would welcome any changes or ideas that REDUCE the number of manual settings during the windows GUI configuration... One thing I DO like about cmake is it good support for a sort of out of source building. At present I have sort of settled on using a '/build' or '/msvc' sub-directory, which is great if you want to do a clean up stronger than the likes of the usual 'clean' options... Onwards and upwards... Regards, Geoff. ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. 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
