Re: [Flightgear-devel] windows.h
On Sunday 27 July 2008 21:24, James Turner wrote: Incidentally, a minor rant - even in the past week, I've seen the 'XXX is being worked on, person YYY has lots of changes which they haven't committed for arbitrary (justifiable) reason ZZZ'. I'd like to get involved in hacking on some actual user-visible changes (see a future email for that), but right now I'm struggling to get a handle on, for example, which bits of the OSG code are being worked on and which aren't. Yes, it seems like a lot the old school developers have gone into hibernation. I know first hand that a number of previously active developers are reluctant to contribute, due to a disproportionate amount of unconstructive negative criticism bestowed upon them by a small number of people on this list. Unfortunately, a significant proportion of well intended new contributers has undergone the same fate. Maybe this is a good opportunity to mention that I'm really pleased to see a number of familiar names frequently reappear on the list (you, Erik, Fred). I hope the rest of the old schoolers will follow. I also hope that this will be the return to a more open discussion of key development issues and the development of a new vision for the future of FlightGear. I also hope that this might be the start of a return to the nice friendly, cooperative and friendly place that this list once was. Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] windows.h
(mostly for Fred, I guess) Whilst cleaning up various headers and includes, I've noticed quite a few files including windows.h, via a section like: #ifdef HAVE_WINDOWS_H # include windows.h #endif Many of these files have no obvious reason to be relying on platform specific code, and I think that the MSVC standard library is now good enough to pull in windows.h if it's required by support functions (hopefully never). I believe gl.h on Windows requires windows.h to be pulled in, but the osg/GL wrapper we're using now takes care of that. So, if someone with access to Win32 fancies doing a quick audit in FG and SG of these, feel free. My (optimistic) hope would be that they can *all* die, since virtually all of our platform code is now in osg, but I'm sure there will be a couple of exceptions. (Timing, maybe? Sockets?) In any case, it would be good to get windows.h out of all the headers, so it's at least only dragged in per compilation unit. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
On Sun, Jul 27, 2008 at 5:03 AM, James Turner wrote:
(mostly for Fred, I guess)
Hi James,
I'll defer to Fred's expertise here, but I'm pretty sure that #include
windows.h does several magic things that are required for a clean compile
on the windows platform.
It wouldn't surprise me if the standard hello world example for windows is:
#include windows.h
main() {
printf(Hello world\n);
}
I'm pretty sure this can't go.
Curt.
Whilst cleaning up various headers and includes, I've noticed quite a
few files including windows.h, via a section like:
#ifdef HAVE_WINDOWS_H
# include windows.h
#endif
Many of these files have no obvious reason to be relying on platform
specific code, and I think that the MSVC standard library is now good
enough to pull in windows.h if it's required by support functions
(hopefully never). I believe gl.h on Windows requires windows.h to be
pulled in, but the osg/GL wrapper we're using now takes care of that.
So, if someone with access to Win32 fancies doing a quick audit in FG
and SG of these, feel free. My (optimistic) hope would be that they
can *all* die, since virtually all of our platform code is now in osg,
but I'm sure there will be a couple of exceptions. (Timing, maybe?
Sockets?)
In any case, it would be good to get windows.h out of all the headers,
so it's at least only dragged in per compilation unit.
Regards,
James
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Curtis Olson: http://baron.flightgear.org/~curt/
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Melchior FRANZ -- Sunday 27 July 2008: I don't see why the noisy include lines aren't then in config.h, rather than in every single code file. Ah, I remember, config.h is also loaded just conditionally. But that's really the root of the annoyance. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Melchior FRANZ a écrit : * Curtis Olson -- Sunday 27 July 2008: It wouldn't surprise me if the standard hello world example for windows is: [...] Wouldn't surprise me either. But I don't see why the noisy include lines aren't then in config.h, rather than in every single code file. My next commit will please you. Most are gone. ;-) The real problem was unneeded inclusion of GLU.h and GL.h that required windows.h -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Curtis Olson -- Sunday 27 July 2008: It wouldn't surprise me if the standard hello world example for windows is: [...] Wouldn't surprise me either. But I don't see why the noisy include lines aren't then in config.h, rather than in every single code file. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Frederic Bouvier -- Sunday 27 July 2008: My next commit will please you. Most are gone. ;-) The real problem was unneeded inclusion of GLU.h and GL.h that required windows.h Sounds good. :-) I've always envisioned a system where every simgear code file includes simgear.hxx and every flightgear file flightgear.hxx. And these two headers would conditionally load config.h, compiler.h or windows.h. The conditional header loading just shouldn't be spread all over the code base. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Melchior FRANZ a écrit : * Frederic Bouvier -- Sunday 27 July 2008: My next commit will please you. Most are gone. ;-) The real problem was unneeded inclusion of GLU.h and GL.h that required windows.h Sounds good. :-) I've always envisioned a system where every simgear code file includes simgear.hxx and every flightgear file flightgear.hxx. And these two headers would conditionally load config.h, compiler.h or windows.h. The conditional header loading just shouldn't be spread all over the code base. That would mean even longer compilation time. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Oh, and while we are at it, this silliness should also disappear: #ifndef __cplusplus # error This library requires C++ #endif If anyone needs to be reminded that foo.hxx is a C++ file then there's no hope. It's just visual noise. I mean, foo.hxx isn't an image or a sound file either, and we don't add a warning for that. ;-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Frederic Bouvier -- Sunday 27 July 2008: That would mean even longer compilation time. Yes, a few milliseconds. Come on! The file is loaded into the file cache and then takes almost *no* time for loading, and not more time for parsing as if it's directly in the code file. Following that argument we shouldn't use *any* headers and just replace all preprocessor instructions with the final code. :-} m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Melchior FRANZ a écrit : * Frederic Bouvier -- Sunday 27 July 2008: That would mean even longer compilation time. Yes, a few milliseconds. Come on! The file is loaded into the file cache and then takes almost *no* time for loading, and not more time for parsing as if it's directly in the code file. Following that argument we shouldn't use *any* headers and just replace all preprocessor instructions with the final code. :-} you have no idea about the cruft windows.h is dragging. It's more or less like if you included *every* files located in /usr/include -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
* Frederic Bouvier -- Sunday 27 July 2008: you have no idea about the cruft windows.h is dragging. True. But I had the impression that you were adding the #if ... #include windows.h #endif to every single file, anyway. :-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Melchior FRANZ a écrit : * Frederic Bouvier -- Sunday 27 July 2008: you have no idea about the cruft windows.h is dragging. True. But I had the impression that you were adding the #if ... #include windows.h #endif to every single file, anyway. :-) You are misinformed. I was adding config.h. Look at the CVS log for the number I removed. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
On 27 Jul 2008, at 16:41, Frederic Bouvier wrote: you have no idea about the cruft windows.h is dragging. True. But I had the impression that you were adding the #if ... #include windows.h #endif to every single file, anyway. :-) You are misinformed. I was adding config.h. Look at the CVS log for the number I removed. A few observations: - there are some *header* files which drag in config.h, which is a major no-no. I'll get this one fixed - header inclusion is a very very real compilation time issue, especially for gcc since they're not shared (MSVC can do magic caching I believe). As I have time / boredom, I'm going to start reviewing header / source files in turn to do minimisation on their include trees. This will basically mean removing all the includes, seeing what breaks, and gradually adding them back in, but it's a bit more scientific than that. The golden rule is headers should be independent (pull in their dependencies) but minimal (not pull in anything they don't directly need). I'm also going to see if there's places where forward declarations in headers can replace actual includes. - config.h is optional, but compiler.h is not, and still exists. In the near future, the only thing it will do is silence some MSVC and MipsPro warnings, but it's still there, and can be hooked for other things. Generic includes of *heavy* headers is definitely not the way to go. And a question: - The sources erratically alternate between using the C-library wrappers and not, i.e include stdio.h vs include cstdio. Is this worth fixing, aside from neat-ness? AFAIK on every system cstdio is just a straight wrapper around stdio.h, so it's a not very useful and extremely noisy (in CVS) change to fix every string.h, stdio.h, stdlib.h and so on. Opinions on doing this? Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
Hi James, On Sunday 27 July 2008 18:06, James Turner wrote: - header inclusion is a very very real compilation time issue, especially for gcc since they're not shared (MSVC can do magic caching I believe). As I have time / boredom, I'm going to start reviewing header / source files in turn to do minimisation on their include trees. This will basically mean removing all the includes, seeing what breaks, and gradually adding them back in, but it's a bit more scientific than that. The golden rule is headers should be independent (pull in their dependencies) but minimal (not pull in anything they don't directly need). I'm also going to see if there's places where forward declarations in headers can replace actual includes. You might be interested in some work done by Thomas Foerster. Thomas has done a fairly detailed analysis of the current interdependencies in FlightGear's include files. IIRC, Thomas has a patched version of FlightGear that already removes most of the interdependencies. These updates are not publicly available yet. I had agreed to review his changes and commit them, as part of one of my current FlightGear priorities, but hadn't gotten around to do so yet. Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
On 27 Jul 2008, at 17:24, Durk Talsma wrote: You might be interested in some work done by Thomas Foerster. Thomas has done a fairly detailed analysis of the current interdependencies in FlightGear's include files. IIRC, Thomas has a patched version of FlightGear that already removes most of the interdependencies. These updates are not publicly available yet. I had agreed to review his changes and commit them, as part of one of my current FlightGear priorities, but hadn't gotten around to do so yet. I'd be happy to review them, can't do the committing part. Incidentally, a minor rant - even in the past week, I've seen the 'XXX is being worked on, person YYY has lots of changes which they haven't committed for arbitrary (justifiable) reason ZZZ'. I'd like to get involved in hacking on some actual user-visible changes (see a future email for that), but right now I'm struggling to get a handle on, for example, which bits of the OSG code are being worked on and which aren't. Eg, I'd like to pitch in and remove lots of cruft in SimGear/scene (and screen) but for all I know someone already has done that work in their local tree. In a way I'm happy to go ahead and fix stuff - if people insist on keeping changes out of the tree, it's their problem when work gets done twice, but it's still frustrating and wasteful. Hmmm, I think I also have an upcoming email about (the difficulty of) getting a handle on who's doing what (i.e project tracking), but it's one of those ones I want to word quite carefully :) Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
James Turner wrote: On 27 Jul 2008, at 16:41, Frederic Bouvier wrote: you have no idea about the cruft windows.h is dragging. True. But I had the impression that you were adding the #if ... #include windows.h #endif to every single file, anyway. :-) You are misinformed. I was adding config.h. Look at the CVS log for the number I removed. A few observations: - there are some *header* files which drag in config.h, which is a major no-no. I'll get this one fixed - header inclusion is a very very real compilation time issue, especially for gcc since they're not shared (MSVC can do magic caching I believe). As I have time / boredom, I'm going to start reviewing header / source files in turn to do minimisation on their include trees. This will basically mean removing all the includes, seeing what breaks, and gradually adding them back in, but it's a bit more scientific than that. The golden rule is headers should be independent (pull in their dependencies) but minimal (not pull in anything they don't directly need). I'm also going to see if there's places where forward declarations in headers can replace actual includes. If you're doing that work, I'd like you to follow a *really* minimalist stance i.e., if a header file only contains pointers or references to another class or includes them as arguments in uninstantiated templates (e.g., osg::ref_ptrfoo), then that classe's include file should not be sucked in; a local class declaration should be made instead. This will generate more work for you, but is really the way to go in terms of reducing compiler dependencies. - config.h is optional, but compiler.h is not, and still exists. In the near future, the only thing it will do is silence some MSVC and MipsPro warnings, but it's still there, and can be hooked for other things. Generic includes of *heavy* headers is definitely not the way to go. And a question: - The sources erratically alternate between using the C-library wrappers and not, i.e include stdio.h vs include cstdio. Is this worth fixing, aside from neat-ness? AFAIK on every system cstdio is just a straight wrapper around stdio.h, so it's a not very useful and extremely noisy (in CVS) change to fix every string.h, stdio.h, stdlib.h and so on. Opinions on doing this In C++ code they should be cstring and friends in order to ensure that the functions are all declared in the std namespace. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
On 27 Jul 2008, at 21:02, Tim Moore wrote:
If you're doing that work, I'd like you to follow a *really*
minimalist stance
i.e., if a header file only contains pointers or references to
another class or
includes them as arguments in uninstantiated templates (e.g.,
osg::ref_ptrfoo), then that classe's include file should not be
sucked in; a
local class declaration should be made instead.
This will generate more work for you, but is really the way to go in
terms of
reducing compiler dependencies.
For pointers, a forward declaration works - for template, auto_ptr and
osg::ref_ptr, I'm not totally clear what you mean. With auto_ptr, the
following can cause problems with virtual destructors not being called
on older (MSVC6, I think) versions of visual studio:
[the following is from memory of several wasted days a couple of years
ago, stepping through the generated assembly of MSVC6. I think I have
the particular case right]
class foo;
class bar
{
// no explicit dtor!
auto_ptrfoo mFoo;
}
class wibble : public foo
{
virtual ~wibble()
{
// highly important stuff
}
}
{
bar a;
a.mFoo.reset(new wibble);
// a goes out out scope, its compiler-generated dtor gets run,
destroying mFoo
}
// error, wibble's dtor was not run
If we're requiring a never MSVC than that, I believe we're fine. And
perhaps you meant something else entirely?
In C++ code they should be cstring and friends in order to ensure
that the
functions are all declared in the std namespace.
Okay, when I'm bored I'll do the monster patches to fix that.
James
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] windows.h
James Turner wrote:
On 27 Jul 2008, at 21:02, Tim Moore wrote:
If you're doing that work, I'd like you to follow a *really*
minimalist stance
i.e., if a header file only contains pointers or references to
another class or
includes them as arguments in uninstantiated templates (e.g.,
osg::ref_ptrfoo), then that classe's include file should not be
sucked in; a
local class declaration should be made instead.
This will generate more work for you, but is really the way to go in
terms of
reducing compiler dependencies.
For pointers, a forward declaration works - for template, auto_ptr and
osg::ref_ptr, I'm not totally clear what you mean. With auto_ptr, the
The header file that defines the template should probably be included, although
a template declaration should suffice. But the argument to the template need
only be forward declared.
following can cause problems with virtual destructors not being called
on older (MSVC6, I think) versions of visual studio:
[the following is from memory of several wasted days a couple of years
ago, stepping through the generated assembly of MSVC6. I think I have
the particular case right]
class foo;
class bar
{
// no explicit dtor!
auto_ptrfoo mFoo;
}
class wibble : public foo
{
virtual ~wibble()
{
// highly important stuff
}
}
{
bar a;
a.mFoo.reset(new wibble);
// a goes out out scope, its compiler-generated dtor gets run,
destroying mFoo
}
// error, wibble's dtor was not run
I'm not sure what's going on in your example, as foo needs to be defined
somewhere in order for wibble to inherit from it. Otherwise there's serious bug
there.
If we're requiring a never MSVC than that, I believe we're fine. And
perhaps you meant something else entirely?
I'm comfortable saying that we need a more recent compiler than MSVC 6.
Tim
In C++ code they should be cstring and friends in order to ensure
that the
functions are all declared in the std namespace.
Okay, when I'm bored I'll do the monster patches to fix that.
James
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
