Re: [Flightgear-devel] Building FlightGear under Vista
Hi Jon, - Jon S. Berndt a écrit : Where will I find the best, most up-to-date guide on downloading the development version of FlightGear from CVS and building it? Can I used MSVC++ Express 2008? 2010? Thanks. I haven't done this in a long, long, time. Jon On the http://flightgear.org/Downloads/source.shtml download page there are several packages listed as being prerequisites. However, it is not stated whether only the binaries are needed, or source code, or ... ? And I also don't see any 2.9.x releases, as is recommended on the FlightGear download page. I updated this document recently : http://gitorious.org/fg/flightgear/blobs/next/docs-mini/README.MSVC I tested the described procedure in a blank virtual machine, so you have good chances to succeed ;-) All the prerequisites are available already compiled from the provided links Anyway, VS2010 is too early for OSG, so stay with 2008 for the moment. Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issues with compiling on Gentoo 64
Jason Cox wrote: 1. is simgear-cs flightgear-cs still required or cn I just use th gitorious versions? simgear-cs is just a customized version of SimGear for terragear-cs to run headless if you don't have a $DISPLAY available. It's not required for general operation of FlightGear. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Good news, switching to Ubuntu 10.04 LTS solved all git problems for me. No idea why Xandros 4.5 gave me problems but Xandros seemed to have abandoned the desktop market anyhow. For what it's worth, I'm very pleased with Ubuntu so far. Erik -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] problem with git v2.0.0 -- unable to run flightgear
Hi all, finally got it all compiled but now I get lots (about 14600) of the following that ends in a segfault Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool After turning log level to bulk it first shows up with the following Initializing scenery subsystem Splash screen progress loading aircraft Reading sound sound from /usr/local/share/FlightGear/Aircraft/c172p/c172-sound.xml Loading sound information for: engstart Loading sound information for: crank Loading sound information for: cough Loading sound information for: engine Loading sound information for: propeller Loading sound information for: rumble Loading sound information for: squeal Loading sound information for: flaps Loading sound information for: wind Loading sound information for: stall Loading sound information for: KAP140Beep Error building technique: findAttr: could not find attribute bool Error building technique: findAttr: could not find attribute bool any ideas as miss using flightgear and want to get back to using it again soon Jason -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
The files config.h-msvc8 and config.h-msvc90 are necessary for a windows build but are now in .gitignore making them inaccessible. Natively windows has no method to generate these files from the .in files, although this is probably possible by installing Perl, and GNU versions of autoconf and automake. - and then learning how to use them ! Could they be put back into the normal distribution path? It was me, who put them into gitignore because these files are created from the respective *.in files during the build. Maybe I am wrong, but if these files are created from some other sources, they don't belong under source control but the source files do. If I understand the current setup correctly, a run of autogen.sh and configure is required to create the config.h-msvcxx files from the .in files before a windows build can run. I think it is very unfortunate that some *nix system has to run a configure script to generate the files needed for a windows build, put them into the source control system to be accessible for windows users. Maybe Frederic can chime in here with a better idea of how to solve this? Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with git v2.0.0 -- unable to run flightgear
any ideas as miss using flightgear and want to get back to using it again soon Do you have the latest data from git but not the latest sources from git? Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issues with compiling on Gentoo 64
these were both pulled down from gitourious today with a git clone command. Be sure to clone the branch 'next' from FlightGear and SimGear. This is the branch for the latest changes. PS. is there a better way of doing things apart from git pull and getting everything ever committed being downloaded in to my local copy? git clone --depth 1 myurl Quote from the manpage: --depth depth Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. HTH, Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
The files config.h-msvc8 and config.h-msvc90 are necessary for a windows build but are now in .gitignore making them inaccessible. Natively windows has no method to generate these files from the .in files, although this is probably possible by installing Perl, and GNU versions of autoconf and automake. - and then learning how to use them ! Could they be put back into the normal distribution path? It was me, who put them into gitignore because these files are created from the respective *.in files during the build. Maybe I am wrong, but if these files are created from some other sources, they don't belong under source control but the source files do. If I understand the current setup correctly, a run of autogen.sh and configure is required to create the config.h-msvcxx files from the .in files before a windows build can run. I think it is very unfortunate that some *nix system has to run a configure script to generate the files needed for a windows build, put them into the source control system to be accessible for windows users. Maybe Frederic can chime in here with a better idea of how to solve this? I originally included config.h-msvcxx in the autoconf system because there was a long track record of releases made with the wrong version in these files. autoconf is only used to substitute @VERSION@ by the right one. No need of perl or something else, just copy the .in file and replace @VERSION@ by a string, ideally the right version number ;-) If someone is able to alter the project file to autogen this file with the good version number, under Windows, without requiring additional tools, go ahead... Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Git merge oops.
I pushed a wrong branch by accident, which will mess up history in the repo. Not the end of the world, but Tim can fix it if people avoid committing to fg (simgear and fgdata are unaffected) until he's rolled back my mistake. There's a separate issue that the build will be broken following my earlier merge - I was trying to fix the build when I did the bad push. (If you're looking at the Gitorious web interface, it's the push of 133 commits that is the issue) Apologies for the SNAFU, James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
-- From: Frederic Bouvier fredfgf...@free.fr Sent: Saturday, June 26, 2010 5:57 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Windows config.h-mscxx The files config.h-msvc8 and config.h-msvc90 are necessary for a windows build but are now in .gitignore making them inaccessible. Natively windows has no method to generate these files from the .in files, although this is probably possible by installing Perl, and GNU versions of autoconf and automake. - and then learning how to use them ! Could they be put back into the normal distribution path? It was me, who put them into gitignore because these files are created from the respective *.in files during the build. Maybe I am wrong, but if these files are created from some other sources, they don't belong under source control but the source files do. If I understand the current setup correctly, a run of autogen.sh and configure is required to create the config.h-msvcxx files from the .in files before a windows build can run. I think it is very unfortunate that some *nix system has to run a configure script to generate the files needed for a windows build, put them into the source control system to be accessible for windows users. Maybe Frederic can chime in here with a better idea of how to solve this? I originally included config.h-msvcxx in the autoconf system because there was a long track record of releases made with the wrong version in these files. autoconf is only used to substitute @VERSION@ by the right one. No need of perl or something else, just copy the .in file and replace @VERSION@ by a string, ideally the right version number ;-) If someone is able to alter the project file to autogen this file with the good version number, under Windows, without requiring additional tools, go ahead... Regards, -Fred Fred Thanks for that. I had just this minute run a diff check on config.h-msc90 (from my CVS archive) and config.h-msc90.in As you say the only difference is that each occurrence of @VERSION@ is replaced by 2.0.0. This is exactly the change that has to be made in simgear/simgear.h.in before it is copied to simgear.h. Is there any need for this to be done by all new cloners before compilation? It seems to be an unnecessary complication. All GIT users should be currently working with the same version (2.0.0) in both simgear and flightgear. As and when a new version comes about both these files can be updated and committed by whoever is responsible for raising the issue number. As an aside I tried to generate config.h-msc90 with cygwin autoconf - but it failed with an error at line 799 in file configure.ac. Alan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
- Alan Teeder a écrit : Is there any need for this to be done by all new cloners before compilation? It seems to be an unnecessary complication. All GIT users should be currently working with the same version (2.0.0) in both simgear and flightgear. As and when a new version comes about both these files can be updated and committed by whoever is responsible for raising the issue number. As an aside I tried to generate config.h-msc90 with cygwin autoconf - but it failed with an error at line 799 in file configure.ac. I forgot to mention I proposed this change in the CVS era before I had commit privilege. It's obvious that now I could commit the file with the correct version number, because I doubt a Linux developer will do it spontaneously ;-). I am away on vacation now so I can't promise when this will be done, but it may be wise to remove the .in files and their reference in configure.ac, and remove the target files from .gitignore -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Git merge oops.
On 26 Jun 2010, at 17:41, James Turner wrote: I pushed a wrong branch by accident, which will mess up history in the repo. Not the end of the world, but Tim can fix it if people avoid committing to fg (simgear and fgdata are unaffected) until he's rolled back my mistake. There's a separate issue that the build will be broken following my earlier merge - I was trying to fix the build when I did the bad push. All fixed now, including the build issues. Apologies again, and thanks to Tim for the speedy fix. James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
On 6/26/10 7:36 PM, Alan Teeder wrote: Is there any need for this to be done by all new cloners before compilation? It seems to be an unnecessary complication. The reason for having autoconf to replace the version string is that there should only be one place where the version string is set (configure.ac or some associated file depending on the build system setup). (Some) Mac and all(?) linux users use autoconf and there is no issue. I suppose the problem of copying the file and changing the string manually affects windows and mac xcode (I think) users. The source file is the .in file and that should be in the repository and nothing else. All GIT users should be currently working with the same version (2.0.0) in both simgear and flightgear. As and when a new version comes about both these files can be updated and committed by whoever is responsible for raising the issue number. Well, technically git users are working on 2.x (or 2.0.x or what ever the next version will be called). Again, the idea is that the version number should only be changed in one place and propagated by the build system. In your case it is a header for MSVC and for other developers the version will be propagated to other files. This type of scenario is error prone. Cheers, Jari -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
On Saturday 26 June 2010 07:55:10 pm Frederic Bouvier wrote: I forgot to mention I proposed this change in the CVS era before I had commit privilege. It's obvious that now I could commit the file with the correct version number, because I doubt a Linux developer will do it spontaneously ;-). Unless that Linux Developer also happens to be the release coordinator and is properly briefed on the need to do so. :-) Cheers, Durk -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] failed assertion
if i try to set the time of day (--timeofday) to anything i get fgfs: sunsolver.cxx:60: void fgSunPositionGST(double, double*, double*): Assertion `sun' failed. Abort without the timeofday flightgear starts normally. this is with the latest git. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] failed assertion
if i try to set the time of day (--timeofday) to anything i get fgfs: sunsolver.cxx:60: void fgSunPositionGST(double, double*, double*): Assertion `sun' failed. Abort without the timeofday flightgear starts normally. this is with the latest git. --alex-- Should be fixed now, thanks for reporting. Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issues with compiling on Gentoo 64
Thanks for that. I have just been using a git clone and letting it decide on what was the working copy. I think it used v2.0.0-r4 or something. All 3 were done the same, I will change them to next. only other nice thing would be a cut down of the fgdata so that I got only minimal data and do the whole shooting match as it is quite extensive and I tend to only fly with the default. any way thats the wish list, now back to seeing if using next branch works better Jason On Sat, 2010-06-26 at 13:36 +0200, Torsten Dreyer wrote: these were both pulled down from gitourious today with a git clone command. Be sure to clone the branch 'next' from FlightGear and SimGear. This is the branch for the latest changes. PS. is there a better way of doing things apart from git pull and getting everything ever committed being downloaded in to my local copy? git clone --depth 1 myurl Quote from the manpage: --depth depth Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. HTH, Torsten -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] failed assertion
On 26 Jun 2010, at 21:00, Torsten Dreyer wrote: Should be fixed now, thanks for reporting. And thanks to Torsten for fixing! James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
