Example taken from hasard: the file fg_props.hxx
the begining of the file is:
// fg_props.hxx - Declarations and inline methods for property handling.
// Written by David Megginson, started 2000.
//
// This file is in the Public Domain, and comes with no warranty.
#ifndef __FG_PROPS_HXX
#define __FG_PROPS_HXX 1
#include <iosfwd>
#include <simgear/structure/subsystem_mgr.hxx>
#include <simgear/math/SGMath.hxx>
#include <Main/globals.hxx>
==> it didnt include the file /simgear/props.hxx which defines namespace
props and enum simgear::props:STRING
but later it uses namespace and the enum defined in it:
class FGMakeUpperCase : public SGPropertyChangeListener {
public:
void valueChanged(SGPropertyNode *node) {
if (node->getType() != simgear::props::STRING) <== here
return;
char *s = const_cast<char *>(node->getStringValue());
for (; *s; s++)
*s = toupper(*s);
}
==> if any of the 4 files included in top of source doesnt include
/simgear/props.hxx than this file doesnt compile: it s abnormal.
The
#include <simgear/structure/subsystem_mgr.hxx>
is absolute includes and depends on the search path added on the project
configuration
If the directory hierarchie is well defined, you can set for example a
relative path
#include ../../../../simgear/structure/subsystem_mgr.hxx
the reader of the source can find immediately where the file included is
and can read it quickly without searching.
I am not against include directory path in project configuration for
example to set up dependencys from external project
Like openscenegraph in flightgear, but, simgear is semi-external, like
jsbsim the sources are compiled in flightgear project
Than it can be considered internal and no include path have to be added
on project, or it can be considered external in the form of a simple lib
to link with and include path in the project are added.
there are other examples where the part simgear/ is missing because the
project configuration include the path:
../../../../simgear
other example : the project configuration include the paths :
../../../src
../../../src/include
=> its abnormal use only one of the two solution and set #include
directive in accordance
other example:
in my first atempt to compile flightgear i have used
Openscenegraph2.9.7 because in the doc it is say that
openSceneGraph2.9.6 and above is needed
OpenSceneGraph2.9.7 doesnt link, an obscure probleme of zlib version
used in openscenegraph2.9.7. I have decided to delete 2.9.7 and using
OpenSceneGraph2.9.6
Than i can link with 2.9.6 version
There must be someone designed to decide wich version of external
software to use and responsible of the good integration and test of the
external modules.
Do not tell to use Version2.9.6 and above, tell use only version
2.9.6 flightgear validated with 2.9.6.
Okay there are tools to setup a new jsbsim in flightgear for example, i
didnt know that before my mail, but i find its not very normal to have
to using tools.
Ok, i am returning to learn how integrate the new jsbsim in FG.
Cordialy,
David Ingels
-----Message d'origine-----
De : Frederic Bouvier [mailto:[email protected]]
Envoyé : mercredi 5 mai 2010 17:34
À : FlightGear developers discussions
Objet : Re: [Flightgear-devel] toow many bugs on flightgear sources
Hi David,
your rant could have more weight if you included some examples. Please
be more specific to help us improve the current situation.
-Fred
----- "Ingels David" <[email protected]> a écrit :
> There is a lot of bugs in the structure of the project
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery - album photo
http://www.youtube.com/user/fgfred64 Videos
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
