Re: [Flightgear-devel] fgdata: Important note
Hi Gijs Am 25.10.11 18:54, schrieb Gijs de Rooy: > No matter what aircraft-split we end up with, aircraft authors will always be > able to update their own aircraft at > any time. Hope so ;-) With the current setup you can for example commit (and accept merge requests) for your EC130:https://gitorious.org/flightgear-aircraft/ec130 But I want to give commit rights to my wife to my repo, without asking you, can I do that ? Why not ? What gives "the team" the right to decide if my wife could be contributor in my aircraft project or not ?! > > When you start on a new aircraft and would like to have its repository under > the FlightGear Aircraft project, you > do have to ask one of the people from "the team": > https://gitorious.org/+flightgear-aircraft For every single aircraft ? Hm, everyone ? > You also have to contact that teammembers when you'd like to get access to an > existing repo (or give someone > else access to your aircraft's repo). "Sorry, Peter is not here since six months, but Paul - ok, he does not know a lot about your project - but he will give access to Alex, to update Sabins repo permissions." Good night. For me it looks much better making hangar teams (or single-aircraft-moviestars when you need) RESPONSIBLE. > We could implement Yves' idea (giving teams access to repos, rather than > individuals) in the FlightGear aircraft > project. But I don't think it is worth most of the trouble. What troubles ? Can you be more specific ? I think it would make things even more un-clear when > there are hundreds of teams... Oh no, I would welcome hundreds of teams in any open source project. Do you fear contribution? Or only administration of contribution? Me, I fear an update of a single aircraft folder with 1000+ aircrafts and tons of cloned and copy/paste aircrafts to download. With hangars I can checkout one "default" submodule and probably one or two specific quality hangars. And when I change something in the code (hell!), I can check it against a common default hangar, and not against 1000+ different aircrafts and clones. > But I might be wrong of course. Me too. ;-) Cheers, Yves -- 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] fgdata: Important note
Am 25.10.11 19:09, schrieb syd adams: > I dont personally see any advantage myself, I'd have to vote no.Sorry Yves. > > -- > 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 > Hi Syd There is nothing to vote yes or no actually. But thanks anyway to read and give some feedback. Cheers, Yves -- 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
[Flightgear-devel] How to remove one cmake warning - asked and answered
Hi All,
In WIN32, building SG, due to the fact that I am
using STATIC OSG and pthread libraries, I added two
entries - OSG_LIBRARY_STATIC and PTW32_STATIC_LIB
to the CMake GUI...
But on SG generation done get
CMake Warning:
Manually-specified variables were not used
by the project.
Well, YES they ARE! See a number of OSG headers
used in SG, and see FG Main\bootstrap.cxx,
Main\util.cxx and Main\fg_os_osgviewer.cxx
and maybe other places...
How, where do I add these - they can default
OFF - to avoid this CMake warning?
That seems important so they will ALSO be added
to the preprocessor definition of ALL projects...
I can see in the root CMakeLists.txt, and entry
set(MSVC_FLAGS "-DWIN32 -DNOMINMAX ...etc... ")
but this is NOT an OPTIONAL addition...
Then I can see other 'options' like
/CMakeLists.txt
option(SIMGEAR_SHARED "Set to ON...etc" OFF)
Then in
simgear\CMakeLists.txt
if(SIMGEAR_SHARED)
...
endif(SIMGEAR_SHARED)
Or another option, JPEG_FACTORY
/CMakeLists.txt
option(JPEG_FACTORY "Enable JPEG..." OFF)
Then in simgear\screen\CMakeList.txt
if(JPEG_FACTORY)
list(APPEND SOURCE jpgfactory.cxx)
...
endif()
So I can sort of see adding to -
/CMakeLists.txt
option(OSG_LIBRARY_STATIC
"Set ON to link with OSG static libraries." OFF)
option(PTW32_STATIC_LIB
"Set ON to ink with static pthread library." OFF)
Then maybe
if(OSG_LIBRARY_STATIC)
set(MSVC_FLAGS "${MSVC_FLAGS} -DOSG_LIBRARY_STATIC")
endif()
if(PTW32_STATIC_LIB)
set(MSVC_FLAGS "${MSVC_FLAGS} -DPTW32_STATIC_LIB")
endif()
OR maybe better, as I read more -
===
if(WIN32)
if(MSVC)
if(OSG_LIBRARY_STATIC)
set(ADDED_FLAGS "${ADDED_FLAGS} -DOSG_LIBRARY_STATIC")
endif()
if(PTW32_STATIC_LIB)
set(ADDED_FLAGS "${ADDED_FLAGS} -DPTW32_STATIC_LIBRARY")
endif()
set(MSVC_FLAGS "-DWIN32 -DNOMINMAX etc ${ADDED_FLAGS}")
endif()
...
Will try that...
YOW, that seemed to have WORKED ;=))
And maybe an improvement would be to have a user
STRING input option, say ADDED_MSVC_FLAGS, where
a user could add these, and any other not thought of
yet options, to the MSVC preprocessor definitions...
but not sure how to set that up yet...
Put me down as an EXPERT CMake tactician ;=
Not really, but learning more each day...
Regards,
Geoff.
PS: James, just read your reply as I was posting
this, so will reply on it tomorrow...
PPS: Now on cmake of FG, after adding the
above STATIC stuff there as well, but have run
into the 'stupid' error -
missing SIMGEAR_VERSION_OK,
but again will have to address that tomorrow...
--
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] Aircraft split
Oh good. I figured someone would be way ahead of me :) Cheers On Tue, Oct 25, 2011 at 11:32 AM, James Turner wrote: > > On 25 Oct 2011, at 14:30, syd adams wrote: > >> I haven't thought it out too deeply , but >> maybe in this format : >> >> Aircraft: Citation-X >> Author: Syd >> Licence: GPL >> URL: git clone or download url >> Splash: path/url to thumbnail >> >> It would be up to the aircraft developers to fill it in and maintain >> it, and possibly a nice little GUI could be created to automate the >> viewing and downloading. >> Just a thought. > > I'm working on pretty much exactly this, only with a bit more intelligence - > version numbers, mirrors, other metadata. It will happen, but there's quite a > few parts to get working - including the GUIs as you mention. > > 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 > -- 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 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 > > > 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///[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
[Flightgear-devel] Terragear now sans plib
Hi there, maybe you have noticed some exceptionally high activity in recent days/weeks on the Terragear repo. Well, there is one particular reason for it: It now supports the cmake build system and, as of today, does no longer depend on plib. These changes are not yet in the master tree, but can be tested in the topics/cmake-integration branch. Please do so, if possible, so we can iron out any showstoppers. Chris -- 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] Aircraft split
On 25 Oct 2011, at 14:30, syd adams wrote: > I haven't thought it out too deeply , but > maybe in this format : > > Aircraft: Citation-X > Author: Syd > Licence: GPL > URL: git clone or download url > Splash: path/url to thumbnail > > It would be up to the aircraft developers to fill it in and maintain > it, and possibly a nice little GUI could be created to automate the > viewing and downloading. > Just a thought. I'm working on pretty much exactly this, only with a bit more intelligence - version numbers, mirrors, other metadata. It will happen, but there's quite a few parts to get working - including the GUIs as you mention. 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] fgdata: Important note
> On the other side clone each of the 300+ aircraft isn't that comfortable as > well. There are various ways to tackle that problem. One could write a script to clone/pull all the aircraft with a single click, but an even nicer solution might be to use "submodules", as mentioned at the wiki (sorry for promoting the wiki this often, but it really makes discussions a lot shorter/better if everyone reads the plan as written down there :P) Gijs -- 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] fgdata: Important note
Hello, >there was little input on the fgdata split and few people speaking up >when things were started. We do see a lot of responses now - many being >in favor of the change, but also concerns about remaining issues. >Indeed, setting up the new repo isn't as simple as it seemed initially, >and there are issues which need to be resolved. We also need common >acceptance of the new structure, tools and processes. >Unfortunately, the call for "split completed" was communicated ahead of >time - even before fgdata itself was switched. And we still do see a >need for a proper testing phase before switching - including a chance >for everyone to give input, raise concerns, etc. Thanks for that- it looked to me like the changes have been made to quick without seeing the consequences. Nethertheless, I'm in favor for a split. My Reasons: -Gitorious.org had problems with the size of our repo. This was one cause why Merge-requests didn't worked for a while. They fixed it, but as the number aircraft are increasing I wonder for how long. -There are countries and locations where download speed isn't really fast, but even very slow. And yes, Germany is indeed one of them -for each small update developers without commit rights it wasn't that comfortable to get them up. For those people I think it wasn't easy as well to find time to work on their own projects and review and commit new updates of aircraft. That was the reason why I set up my own repos. It was easier for to organize my work, still open and free for users even if they want to contribute, tar.gz was made automatically (no need of uploading to my Homepage), and still had the possibility to let commit it to FGdata. On the other side clone each of the 300+ aircraft isn't that comfortable as well. I would rather liked to see a "FGAircraft" or "FGAicraftFixedWings","FGAicrafthelicopters",... Heiko -- 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] fgdata: Important note
I dont personally see any advantage myself, I'd have to vote no.Sorry Yves. -- 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] FW: Skydome and Terrain shader with haze - some helprequired
Hi, On Monday, October 24, 2011 10:27:11 thorsten.i.r...@jyu.fi wrote: > My understanding is that > > * the vertex shader computes stuff for each vertex Yes. > If I don't use a fragment shader (as e.g. in the 3dclouds), things like > shading get a linear interpolation between vertices. You need to have both shaders if you use one of them. Just using one of which is not allowed by gl. To understand what happens I try to give a brief sketch on how this works: varying results from the vertex shader are fed into the rasterizer which takes the primitives and the varyings at the corners and generates fragments (pixels) for these geometries. The scanline algorithm is applied to the varyings which means along the edges of the primitives the varying is interpolated linearily according to its position between the vertices. Then along the scanline the varying result is taken at the two endpoints that are located on the edges the varying is again linearily interpolated for each fragment. This is still the same than it was done in the good old fixed function pipeline days. Just that you have today a variable amount of varyings with arbitrary names that are handled like the above. > * the fragment shader allows me to specify a non-linear function to > interpolate between vertices Hmm, I do not understand this. Understand the above and it gets clear what happens. > If I have two points with distances d1 and d2, I can either compute fog1 = > exp(-d1/vis) and fog2 = exp(-d2/vis) in the vertex shader. > > The result will then be a linear increase in fog from fog1 at d1 to fog2 > at d2 - which is in general very wrong for large d1-d2 because the actual > result is exponential and not linear. Or I can pass d1 and d2 to the > fragment shader and compute the non-linear exponential there - which would > give me the correct result, since a linear interpolation between d1 and d2 > actually should be an exact result. Ok, I see: In other words you are correclty claiming that exp(x*a) != x*exp(a) which just means that the exponential is *not* a linear function. Which means you can't just pull that out of the fragment shader into the vertex stage without changing the results. :) > So there should in fact not be any loss of accuracy when I move linear > quantity computations to the vertex shader, this should only be true if I > move non-linear quantities. > > Is this essentially correct? Essentially yes. Hope this helps 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] fgdata: Important note
Hi, good to see some more factual discussions. Let me emphasize that anyone is welcome to add/edit concerns/questions/answers/solution to the wiki: http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata > Those who have commit rights are already busy with their own stuff. For a new > aircraft it is o.k. to ask them- > but when I want to update my work? For each small update asking and stealing > time of those people? No matter what aircraft-split we end up with, aircraft authors will always be able to update their own aircraft at any time. With the current setup you can for example commit (and accept merge requests) for your EC130:https://gitorious.org/flightgear-aircraft/ec130 When you start on a new aircraft and would like to have its repository under the FlightGear Aircraft project, you do have to ask one of the people from "the team": https://gitorious.org/+flightgear-aircraft You also have to contact that teammembers when you'd like to get access to an existing repo (or give someone else access to your aircraft's repo). We could implement Yves' idea (giving teams access to repos, rather than individuals) in the FlightGear aircraft project. But I don't think it is worth most of the trouble. I think it would make things even more un-clear when there are hundreds of teams... But I might be wrong of course. Cheers, Gijs -- 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] fgdata: Important note
Hello, >IMHO that adds another not very logical layer of complication for little >>gain. There's a nice "democratic" aspect to every aircraft being in a >>single central repository, and reduced opportunities for those "clique" >type >groups that so naturally spring up and are divisive and very >offputting to >new contributers coming to the project. Sorry, I hate it to say, but we have that situation already. >Up until now it's been very straightforward to get a new model included - >if >it's your own work and under a suitable licence you simply ask someone >with >commit rights if you know one, or offer it to the dev list and it >goes in. >There's no embarrasment over which hangar / group / clique to >submit it to, >and I think that's a very good thing. So far it is working. BUT: Those who have commit rights are already busy with their own stuff. For a new aircraft it is o.k. to ask them- but when I want to update my work? For each small update asking and stealing time of those people? But the last sentence is not true again, sorry. It should be like that, but it isn't any more. The idea of Yves aka HB-GRAL is quite nice and seems to me to reflect the actual situation. But I must admit- in the whole thing I'm quite uncertain how to proceed. I just know that the current FGData make more and more problems with its size! -- 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
[Flightgear-devel] OpenRTI git repository
Hi, Some of you have already noticed that berlios is closing at the end of the year. So OpenRTI needs to find a new home. I have recently just changed my upstream repository to git://gitorious.org/openrti/openrti.git This is not a full replacement for the berlios site, but currently at least the location of the git repository. Still thinking about what to do with mainling lists, that were until now unused, and bug tracking and so on. If you have problems with anything there feel free to contact me. thanks Mathias -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabling HLA - missing RTI.hh
On Monday, October 24, 2011 22:12:15 Martin Spott wrote: > George Patterson wrote: > > Btw, Berlios is closing on 31/12/2011 so grab what you need now. I am > > not sure if Mathias has moved the above project to another host. > > I'm sure Mathias will speak about the details himself, but aside from > that I can confirm he's aware of the implications. In case of doubt, > there's our mirror at: > > http://mapserver.flightgear.org/git/gitweb.pl?p=openrti Uh, you alredy mirrored this one?! Ok. I am currently thinking of what to do with the project. But in the meantime my upstream git is now at gitorious: https://gitorious.org/openrti/openrti with the git clone url: git://gitorious.org/openrti/openrti.git So berlios is already considered dead ... 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 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 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
Re: [Flightgear-devel] fgdata: Important note
On Tue, 25 Oct 2011 00:18:36 +0200 HB-GRAL wrote: > Hi Core (and the rest of the entire organism of course) > Why not splitting up the Aircraft folder into hangars as collection of > aircrafts as plug-ins, collection of big teams or small but heavy > industries ? IMHO that adds another not very logical layer of complication for little gain. There's a nice "democratic" aspect to every aircraft being in a single central repository, and reduced opportunities for those "clique" type groups that so naturally spring up and are divisive and very offputting to new contributers coming to the project. Up until now it's been very straightforward to get a new model included - if it's your own work and under a suitable licence you simply ask someone with commit rights if you know one, or offer it to the dev list and it goes in. There's no embarrasment over which hangar / group / clique to submit it to, and I think that's a very good thing. Cheers, AJ -- -- 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
[Flightgear-devel] Aircraft split
Hi . Though it appears to have it's drawbacks , from a selfish point of view ,the split makes work here much easier. Thanks again. Just another (possibly useless) idea . What about adding a text/xml file of all available aircraft , or even an aircraft.dat file,somewhere in fgdata? I haven't thought it out too deeply , but maybe in this format : Aircraft: Citation-X Author: Syd Licence: GPL URL: git clone or download url Splash: path/url to thumbnail It would be up to the aircraft developers to fill it in and maintain it, and possibly a nice little GUI could be created to automate the viewing and downloading. Just a thought. Cheers -- 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] Fgpanel and ubuntu 11.10 build linking failed on libz, solved.
Am 24.10.2011 13:08, schrieb James Turner: > [...] > Also, there is something configuration dependent happening here, > since other people have reported a similar issue (also with Ubuntu > 11) on IRC, but I don't see the issue on my Ubuntu install. > > Anyone else seeing this problem (on any other distribution?) At least on Ubuntu 11.10 64bit, some libraries have been moved from /usr/lib to /usr/lib/x86_64-linux-gnu, among which are at least libz.so and libGLU.so. I also ran into linking problems with these two libs after upgrading from 11.04, but after deleting the CMake cache and re-configuring (both SimGear and FlightGear), everything went fine. Best regards, Andreas -- 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 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
