Re: [Flightgear-devel] SimGear include path (was: YASim)
Andy Ross wrote: Is that correct? In my SimGear installation tree, easyxml.h is under /simgear, there is no /simgear/xml directory. In the SimGear *source* tree, that's where the file is. But you're not supposed to be building against the source tree. I suspect you have a bug in your project configuration. No. I'm using the latest CVS. And the file lives (on my System) in K:\Projekte\SimGear\simgear\xml so it's definitely /simgear/xml. And it's doing that for quite a while. In the simgear directory itself are only 5 header files. And when you have a look in the rest of flightgear it's also including the file via the xml directory. Perhaps your SimGear is too old? CU, Christian PS: My project configuration is a direct mapping of the directory layout. -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] SimGear include path (was: YASim)
Andy Ross writes: Is that correct? In my SimGear installation tree, easyxml.h is under /simgear, there is no /simgear/xml directory. In the SimGear *source* tree, that's where the file is. But you're not supposed to be building against the source tree. I suspect you have a bug in your project configuration. My fault -- I left out the includedir = statement at the top of simgear/misc/Makefile.am, and as a result, easyxml.hxx has always been installed in the wrong place. We never noticed that, because I was careful to make sure that header files didn't reference it (I like encapsulation). Andy is the first easyxml user outside the property manager, so this is the first time the problem has come up. Andy: would you object if I made the fix in YASim in the FlightGear CVS tree after fixing the problem in SimGear? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear include path (was: YASim)
David Megginson wrote: Andy is the first easyxml user outside the property manager, so this is the first time the problem has come up. Andy: would you object if I made the fix in YASim in the FlightGear CVS tree after fixing the problem in SimGear? Not at all, we should clearly have the file in the same place in both the source and install trees. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear include path (was: YASim)
Andy Ross wrote: Christian Mayer wrote: Andy Ross wrote: Is that correct? In my SimGear installation tree, easyxml.h is under /simgear, there is no /simgear/xml directory. In the SimGear *source* tree, that's where the file is. But you're not supposed to be building against the source tree. I suspect you have a bug in your project configuration. No. I'm using the latest CVS. And the file lives (on my System) in K:\Projekte\SimGear\simgear\xml That's the source tree -- the stuff you've checked out of CVS. Under the autoconf build procedures, there's a make install step that puts the SimGear header files into a specified target directory (the default is /usr/local/include/simgear). When installed, easyxml.h goes into /usr/local/include/simgear/easyxml.h. Ah, ok. But the autoconf build process is unportable and shouldn't be relied on. So IMHO (and out of the MSVC perspective) the files should be included as seen in the source tree. OK, that's a quite narrow minded view (as well as the opposite direction would be). I think David's suggestion is the best to fix the autoconf. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear include path (was: YASim)
Andy Ross writes: Andy: would you object if I made the fix in YASim in the FlightGear CVS tree after fixing the problem in SimGear? Not at all, we should clearly have the file in the same place in both the source and install trees. Done -- everyone please make sure you do a new make install in SimGear before rebuilding FlightGear. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear include path (was: YASim)
David Megginson wrote: Andy Ross writes: The reason this bites only YASim, I suspect, is that I'm the only non-SimGear code that actually uses this file. Everything else uses the PropertyTree wrapper parser instead. I didn't know about this at the time, so I just used the raw SAX-like parser instead. Andy -- your XML looks fine, and a property-based version would be more verbose, but if you'd like the extra flexibility (and consistency), I'll be happy to help you switch over. The advantage to the property interface, to me, isn't so much that the configuration would end up in the property system (nothing but the YASim parser should ever be touching the aircraft configuration files at runtime, anyway). It's that you get a single parse tree as the output, instead of having to handle things piecemeal in callbacks. I tend to agree -- the property scheme would be more verbose and less readable than attributes. Quite honestly, I'm not a big fan of XML for this reason; it's data model doesn't quite fit the one most programs use internally. The choice as to use an attribute or subtag is very non-orthogonal, ordering constraints for sub-parts is only implied (this makes list of N or more constructs a little clumsy), there's the nasty possibility that you will have data in places you don't want, whitespace handling is nonspecified (i.e. is a 2.3 /a equal to a2.3/a or not?). I could go on with a bunch of complaints and nits. On the other hand, it's a standard metadata format with readily available parsers for every programming environment imaginable, and this world *DESPERATELY* needs a standard metadata format. So I live with it without complaining too much. It just isn't what I would have picked. ;) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
