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
[Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
= IMPORTANT NOTICE TO EVERYONE INVOLVED WITH THE DEVELOPMENT OF FGDATA OR AIRPLANES THEREIN = Thanks to the concentrated effort of all people involved, most notably Jorg - who I'd hereby like to thank on behalf of all of us, for spending three successive days and nights branching, cloning, filtering, splitting and verifying data - FGDATA has, by today, successfully been split into individual repositories, comprising the respective planes and FGDATA core data. Again: === !!! === From the present day on, the development version of FGDATA NO LONGER CONTAINS ANY AIRPLANES - You will have to clone a new FGDATA! === - Airplanes migrated - All airplanes, hitherto found in $FGDATA/Aircraft/, have been removed from that place in the development version of FGDATA and can presently be found in their individual repositories at the following URL https://gitorious.org/flightgear-aircraft (Disclaimer: HTML page is rather huge) Please contact either of the following administrators to be given priviledges on one of those repositories: https://gitorious.org/+flightgear-aircraft/memberships - New FGDATA Core - FGDATA is now without any aircraft. The only things which remain in FGDATA's Aircraft directory are general purpose data which are used by a bulk of different airplanes. The respective directories of these data are Generic Instruments Instruments-3d Despite its name, now a historical relict, NO AIRCRAFT SHALL EVER BE PUSHED TO $FGDATA/Aircraft. The new FGDATA can be found in the official repository at the following URL https://gitorious.org/fg/fgdata-new The repository is named fgdata-new for the time being and the old fgdata is kept arround, frozen, to have a fallback if anything should happen. Please contact either of the following administrators to be given priviledges on the new fgdata repository: https://gitorious.org/+flightgear-developers/memberships - Development - All aircraft related development shall henceforth be performed on repositories which are maintained by the respective authors. It is planned that most of the repositories on https://gitorious.org/flightgear-aircraft will be dissolved over time and be taken over by the respective authors. On a sidenote, some of those repositories are already superflous because development has long been moved somewhere else. These are the first repositories which will be decomissioned. Only repositories for which no author is found will remain stored centrally. Development on the rest of FGDATA will continue in the new FGDATA repository until further notice, possibly until more components are migrated, as it has been brought forward. https://gitorious.org/fg/fgdata-new - Usage - To keep up with the new structure, commit all your local changes on your old FGDATA and move its directory out of the way (for example by renaming it). $ cd fgdata $ git commit -a $ cd .. $ mv fgdata fgdata-OLD Next, clone the new repository of FGDATA $ git clone git://gitorious.org/fg/fgdata-new.git fgdata IF YOU HAD LOCAL CHANGES, you will need to reapply these changes. This could be a little adventurous, because these are actually two separate repositories and you can't just rebase. You'll have to prepare the patches and apply them over. If you need help with this, check on the official IRC channel at irc://irc.flightgear.org/flightgear for help. Now you have the new core FGDATA (possibly with your own changes, if you followed the hint above). In the coming days, we will provide you with scripts which conveniently fetch your personal selection of aircrafts; until then you will have to manually obtain them from the repositories. Here is how: DO NOT PUT THE AIRCRAFTS INTO THE NEW FGDATA! Instead, create a new directory somewhere completely different, say, /usr/local/flightgear/aircrafts and store the aircrafts in there (for example clone them from their repositories). If you specify that directory on the command line to Flightgear, it will find them, altough they are not in the FGDATA directory. E.g.: $ ./fgfs --fg-aircraft=/usr/local/flightgear/aircrafts NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === If you are experiencing problems you can find people who can help you on IRC. regards, ManDay, on behalf of the Split-Team ^^ -- 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
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Good work guys. Thanks. On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote: NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === Surely that would be a bug in the aircraft that should be fixed? Also, IIRC there are a number of aircraft that have dependencies on other aircraft. Presumably this would be a good opportunity to fix those as well? -Stuart -- 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] FGData Split Completed - a.k.a. Life after the Split
On Tue, Oct 18, 2011 at 05:33:23PM +0100, Stuart Buchanan wrote: On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote: NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === Surely that would be a bug in the aircraft that should be fixed? Indeed. Also, IIRC there are a number of aircraft that have dependencies on other aircraft. Presumably this would be a good opportunity to fix those as well? Agreed. ManDay -Stuart -- 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] FGData Split Completed - a.k.a. Life after the
The 'fgdata'-mirror at: http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata which previously had been maintained for it's advantageous download performance is now frozen, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] FGData Split Completed - a.k.a. Life after the Split
Am 18.10.2011 18:24, schrieb Cedric Sodhi: Next, clone the new repository of FGDATA $ git clone git://gitorious.org/fg/fgdata-new.git fgdata For some reason, there seems to be no ssh url available for fgdata-new and the aircraft projects? 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] FGData Split Completed - a.k.a. Life after the Split
Torsten wrote: For some reason, there seems to be no ssh url available for fgdata-new and the aircraft projects? There is. g...@gitorious.org:fg/fgdata-new.git and for the aircraft it's like g...@gitorious.org:flightgear-aircraft/c172p.git (all aircraft repos simply match the respective aircraft's directory name). You mean you don't see it at Gitorious? Works fine here on IE9 and FF7... Cheers, Gijs -- 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] FGData Split Completed - a.k.a. Life after the Split
Am 18.10.2011 19:30, schrieb Gijs de Rooy: Torsten wrote: For some reason, there seems to be no ssh url available for fgdata-new and the aircraft projects? There is. g...@gitorious.org:fg/fgdata-new.git mailto:g...@gitorious.org:fg/fgdata-new.git and for the aircraft it's like g...@gitorious.org:flightgear-aircraft/c172p.git mailto:g...@gitorious.org:flightgear-aircraft/c172p.git (all aircraft repos simply match the respective aircraft's directory name). You mean you don't see it at Gitorious? Works fine here on IE9 and FF7... Sorry, I was referring to the clone/push url. Surely the gitorious web site works as expected. The ssh url is required (iirc) to access gitorious with the public key as a commiter. git clone g...@gitorious.org:fg/fgdata-new data fails with Cloning into data... == Gitorious: == Access denied or bad command fatal: The remote end hung up unexpectedly before I can enter my private key. 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] FGData Split Completed - a.k.a. Life after the Split
Torsten wrote: git clone g...@gitorious.org:fg/fgdata-new data Make sure you don't forget .git. Use this: git clone g...@gitorious.org:fg/fgdata-new.git data -- 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
[Flightgear-devel] FlightGear aircraft repository
On 18.10.2011 18:24, Cedric Sodhi wrote: All aircraft related development shall henceforth be performed on repositories which are maintained by the respective authors. It is planned that most of the repositories on https://gitorious.org/flightgear-aircraft will be dissolved over time and be taken over by the respective authors. On a sidenote, some of those repositories are already superflous because development has long been moved somewhere else. These are the first repositories which will be decomissioned. I don't think this is what we agreed upon. We agreed to split fgdata for technical reasons, to cut it into smaller chunks and make it easier to maintain. With separate repos we can give each author direct commit rights - without requiring full access to the rest of fgdata. But there was no agreed decision to dissolve our central community aircraft repository. And personally I think that would be a very, very bad idea to do so. If you look at our aircraft, you'll see the history go way back to the very beginning of FlightGear. Meanwhile, many aircraft developers have joined and left the project. Many private hangars have been created, shutdown, some were lost. The only aircraft which are guaranteed to live on are those in a repository controlled by the FlightGear community. It's not a guarantee forever - but it's a guarantee that is connected to the FlightSim (core / source code) itself - which is what really matters. A community repo has a lot of advantages. When people leave, work isn't lost - maintenance kind of automatically transfers to the community. When really necessary, we can also apply patches - i.e. when something about the flight sim itself has to be changed and aircraft really need to be adapted (which we usually try to avoid, of course). A central repo also allowed us to use the bug tracker for aircraft issues. No one is going to work the bug tracker for issues which affect aircraft living in some dodgy private hangar, probably in 8 different versions maintained by 3 different authors - and we're going to see loads of aircraft forks, without an official repo. We'd also be seeing fewer GPLed aircraft. So far, we had the strict rule: only GPLed stuff was accepted - which was very good for the project. Without such a central hangar, there is one reason less for GPL. And when the majority of aircraft wasn't GPLed any longer, FlightGear will be much less attractive. And why should someone work on _GPLed_ FG core sources - if the rest isn't? The aircraft in our main repository are worth a lot. It's been there for many, many years and it took many, many hours to create. The aircraft probably account for far more than 50% of the time spent on creating FlightGear. It'd be extremely unfortunate to drop all this from the FG community project. And only being slightly provocative: if splitting FGDATA now turns toward a path of breaking up our FG aircraft - I'll rather propose to keep the existing FGDATA. So, before any such major decision affecting the community is made here, I would really like everyone's opinion. Especially Curt's... cheers, Thorsten PS: The old git repo was only 4GB in size: 3GB of git history for aircraft, 1GB for the rest. It was looking much bigger of course, once a git branch was checked out - since files were copied into the working directory (doubles the size) and also decompressed (factor 2). -- 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] FlightGear aircraft repository
Hi all! Cedric wrote: ManDay, on behalf of the Split-Team ^^ ThorstenB wrote: I don't think this is what we agreed upon. I'd like to mention that Cedric did not wrote his email on my behalf nor on Jorg's. Cedric has been a great help (most of this wouldn't be possible without him) and for most of the process we agree, but we disagree with the dissolving of aircraft repos. My plan is still to keep the aircraft under the FlightGear Aircraft project, as written down on the wiki page http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata I did not add 387 repositories to Gitorious (by hand!) to see them dissolve ;) After a simple test I found out that granting admin rights to aircraft authors will also mean that they can revoke the flightgear-aircraft team's rights. And if that is done, we'd have no control over the repo whatsoever. We even would be unable to delete it (only way is to delete the entire project, but as you can imagine that isn't a way). I've added this to the Questions section at the wiki. Please see if you can answer/ask any other questions/concerns: http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata#Questions Therefore I think we shouldn't give aircraft authors full admin rights over their aircraft's repos. I did add all fgdata-developers and flightgear-developers to the flightgear-aircraft team, so anyone that was able to push to fgdata/flightgear should be able to push to all aircraft repos. Please let me know when you're missing. Cheers, Gijs -- 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] FGData Split Completed - a.k.a. Life after the Split
Am 18.10.2011 19:45, schrieb Gijs de Rooy: Torsten wrote: git clone g...@gitorious.org:fg/fgdata-new data Make sure you don't forget .git. Use this: git clone g...@gitorious.org:fg/fgdata-new.git touche - I'm getting too old for this ;-) It works now, thanks! 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] FGData Split Completed - a.k.a. Life after the Split
On Tue, Oct 18, 2011 at 5:33 PM, Stuart Buchanan wrote: On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote: NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === Surely that would be a bug in the aircraft that should be fixed? ... and it has now been. You should now be able to use the c172p outside of the fgdata/ directory. -Stuart -- 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] FlightGear aircraft repository
On Tue, Oct 18, 2011 at 09:46:58PM +0200, Gijs de Rooy wrote: Hi all! Cedric wrote: ManDay, on behalf of the Split-Team ^^ ThorstenB wrote: I don't think this is what we agreed upon. I'd like to mention that Cedric did not wrote his email on my behalf nor on Jorg's. Hello, I apologize for wrongly inserting the suggestion to dissolve the repos on your behalf. I think the other parts of the E-Mail, the description etc, were very well composed on your behalf, though. As for the topic brought up here, I sense a bit of sentimentalism clouding the technical judgment of some. Fact is, that quite a few aircrafts of the old FGDATA are nowadays developed elsewhere. I recall at least having witnessed this twice, although I've only tried a few airplanes. If I recall correctly, skyop's magnificant Bombardier is one of those planes which are developed launchpad and is only represented in FGDATA-Airplanes for historical reasons. Regardless, your arguments why a central repository would be an advantage, minus the sentimental it has always been like that parts, esp. the one about authors joining and leaving, are more or less orthogonal to the philosophy of the development structure which you employ: Git and Gitorious. A central facility, which collects all planes, yes, that makes sense. Actually, I see not how such thing could possibly be forgone. But forcing all aircraft development under the patronage of the core developers is without any practical footing. You are not helping anyone, nor are you supporting GPL. If people want to publish under the GPL, they will do so. If not, they wont. Regardless of whether you coerce them to publish their planes in your master-repository, but only as GPL. Neither do you provide any more guarantee by herding developers into your central repository. You are only patronizing them. You cannot guarantee for someone else's property. And if it's not their property for it's GPL, you can always keep yourself a backup-copy or a clone of their repository, if you are worried about guarantees. Not only are all these alleged advantages pretty much contrived, there are also disadvantages in urging people to play in your opera rather than their own. Restrictions are always harmful to voluntary work. If I, for example, am a LP user and you are trying to lure me come, come to us, here is where the good things happen to your repository, I will rather turn away - as opposed to an OPEN development structure where people are encourage to develop whereever, however they want and simply announce their contribution centrally. History has shown what that concept of a centralized master-repo has lead to: A thick jungle of half-finished, unmaintained and completely abandoned planes, happily mixed with high-quality planes, relicts of planes which have long been migrated to development elsewhere and practically everone has lost orientation in your master-repo. This is not how Git works. This is not how modular contribution on open software works. This is not how Gitorious works. It's most likely counter productive, as has been the unnavigable jungle of planes in the first place. In a positive creative development structure you leave the contributors their freedom. Contribute your planes! rather than Come to Gitorious, ask for our permission to get your repository, work under our supervision! Work, work, my busy bees, and make us planes for our big master-repository! ...to be equally provocative. kind regards, ManDay -- 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.
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 10/18/2011 10:24 AM, Cedric Sodhi wrote: = IMPORTANT NOTICE TO EVERYONE INVOLVED WITH THE DEVELOPMENT OF FGDATA OR AIRPLANES THEREIN = Thanks to the concentrated effort of all people involved, most notably Jorg - who I'd hereby like to thank on behalf of all of us, for spending three successive days and nights branching, cloning, filtering, splitting and verifying data - FGDATA has, by today, successfully been split into individual repositories, comprising the respective planes and FGDATA core data. Again: === !!! === From the present day on, the development version of FGDATA NO LONGER CONTAINS ANY AIRPLANES - You will have to clone a new FGDATA! === - Airplanes migrated - All airplanes, hitherto found in $FGDATA/Aircraft/, have been removed from that place in the development version of FGDATA and can presently be found in their individual repositories at the following URL https://gitorious.org/flightgear-aircraft (Disclaimer: HTML page is rather huge) Please contact either of the following administrators to be given priviledges on one of those repositories: https://gitorious.org/+flightgear-aircraft/memberships - New FGDATA Core - FGDATA is now without any aircraft. The only things which remain in FGDATA's Aircraft directory are general purpose data which are used by a bulk of different airplanes. The respective directories of these data are Generic Instruments Instruments-3d Despite its name, now a historical relict, NO AIRCRAFT SHALL EVER BE PUSHED TO $FGDATA/Aircraft. The new FGDATA can be found in the official repository at the following URL https://gitorious.org/fg/fgdata-new The repository is named fgdata-new for the time being and the old fgdata is kept arround, frozen, to have a fallback if anything should happen. Please contact either of the following administrators to be given priviledges on the new fgdata repository: https://gitorious.org/+flightgear-developers/memberships - Development - All aircraft related development shall henceforth be performed on repositories which are maintained by the respective authors. It is planned that most of the repositories on https://gitorious.org/flightgear-aircraft will be dissolved over time and be taken over by the respective authors. I don't understand the above (up to - Development -). Questions: 1. Are you saying that aircraft developers cannot leave their aircraft in https://gitorious.org/flightgear-aircraft indefinitely? So do we need to set up our own git repository for each ac we maintain? This raises the knowledge/experience bar required for aircraft developers/maintainers. 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? 3. Is there any interest in creating repositories by ac class/type? e.g. historical, military-fighter, military-transport, civilian-light-ac, airliners, etc. By the way, thanks for all the work on this and also for this helpful note of documentation! On a sidenote, some of those repositories are already superflous because development has long been moved somewhere else. These are the first repositories which will be decomissioned. Only repositories for which no author is found will remain stored centrally. Development on the rest of FGDATA will continue in the new FGDATA repository until further notice, possibly until more components are migrated, as it has been brought forward. https://gitorious.org/fg/fgdata-new - Usage - To keep up with the new structure, commit all your local changes on your old FGDATA and move its directory out of the way (for example by renaming it). $ cd fgdata $ git commit -a $ cd .. $ mv fgdata fgdata-OLD Next, clone the new repository of FGDATA $ git clone git://gitorious.org/fg/fgdata-new.git fgdata IF YOU HAD LOCAL CHANGES, you will need to reapply these changes. This could be a little adventurous, because these are actually two separate repositories and you can't just rebase. You'll have to prepare the patches and apply them over. If you need help with this, check on the official IRC channel at irc://irc.flightgear.org/flightgear for help. Now you have the new core FGDATA (possibly with your own changes, if you followed the hint above). In the coming days, we will provide you with scripts which conveniently fetch your personal selection of aircrafts; until then you will have to manually obtain them from the repositories. Here is how: DO NOT PUT THE AIRCRAFTS INTO THE NEW FGDATA! Instead, create a new directory somewhere completely different, say, /usr/local/flightgear/aircrafts and store the aircrafts in there (for example clone them from their repositories). If you specify that directory on the command line to Flightgear, it will find them, altough they are not in the FGDATA directory. E.g.: $ ./fgfs
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] FlightGear aircraft repository
On Tuesday 18 October 2011 15:56:54 Cedric Sodhi wrote: On Tue, Oct 18, 2011 at 09:46:58PM +0200, Gijs de Rooy wrote: Hi all! Cedric wrote: ManDay, on behalf of the Split-Team ^^ ThorstenB wrote: I don't think this is what we agreed upon. I'd like to mention that Cedric did not wrote his email on my behalf nor on Jorg's. Hello, I apologize for wrongly inserting the suggestion to dissolve the repos on your behalf. I think the other parts of the E-Mail, the description etc, were very well composed on your behalf, though. As for the topic brought up here, I sense a bit of sentimentalism clouding the technical judgment of some. Fact is, that quite a few aircrafts of the old FGDATA are nowadays developed elsewhere. I recall at least having witnessed this twice, although I've only tried a few airplanes. If I recall correctly, skyop's magnificant Bombardier is one of those planes which are developed launchpad and is only represented in FGDATA-Airplanes for historical reasons. Regardless, your arguments why a central repository would be an advantage, minus the sentimental it has always been like that parts, esp. the one about authors joining and leaving, are more or less orthogonal to the philosophy of the development structure which you employ: Git and Gitorious. A central facility, which collects all planes, yes, that makes sense. Actually, I see not how such thing could possibly be forgone. But forcing all aircraft development under the patronage of the core developers is without any practical footing. You are not helping anyone, nor are you supporting GPL. If people want to publish under the GPL, they will do so. If not, they wont. Regardless of whether you coerce them to publish their planes in your master-repository, but only as GPL. Neither do you provide any more guarantee by herding developers into your central repository. You are only patronizing them. You cannot guarantee for someone else's property. And if it's not their property for it's GPL, you can always keep yourself a backup-copy or a clone of their repository, if you are worried about guarantees. Not only are all these alleged advantages pretty much contrived, there are also disadvantages in urging people to play in your opera rather than their own. Restrictions are always harmful to voluntary work. If I, for example, am a LP user and you are trying to lure me come, come to us, here is where the good things happen to your repository, I will rather turn away - as opposed to an OPEN development structure where people are encourage to develop whereever, however they want and simply announce their contribution centrally. History has shown what that concept of a centralized master-repo has lead to: A thick jungle of half-finished, unmaintained and completely abandoned planes, happily mixed with high-quality planes, relicts of planes which have long been migrated to development elsewhere and practically everone has lost orientation in your master-repo. This is not how Git works. This is not how modular contribution on open software works. This is not how Gitorious works. It's most likely counter productive, as has been the unnavigable jungle of planes in the first place. In a positive creative development structure you leave the contributors their freedom. Contribute your planes! rather than Come to Gitorious, ask for our permission to get your repository, work under our supervision! Work, work, my busy bees, and make us planes for our big master-repository! ...to be equally provocative. kind regards, ManDay My own, personal reasons for developing my planes 'elsewhere' and having them migrated into the master repository is because I do not have access to the master repository. I would/will happily migrate all of my aircraft work to fg_aircraft and remove the old repositories if I have commit access to my planes. I think Gjis has the correct sense: if my aircraft is in the master repository, I expect the code developers to take some care that it will not bit-rot because they make a change. If the aircraft is elsewhere, GPL or not, the code developers do not have that obligation. Also, having an aircraft in the common repository invites others to join in and make changes. That is how I got started in this whole mess in the first place. $0.02 Thanks, Ron -- 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
