> The good news: > SimGear and FlightGear work with gcc's precompiled headers
This is good news; however, I must say that I have working code (albeit very heavily template-laden, much more than FG), that doesn't work with the gcc's precompiled headers, even with the gcc4.x; so I wouldn't trust this feature altogether. Some failures are obscure runtime ones. > The not so good news: > Some of the necessary changes are not in cvs > > The really bad news: > Some of the necessary changes would have to be done in an > associated project, and even if that were accepted, it couldn't > be maintained there, and the capability soon be lost. > WRT the changes: I found that the best way to make the pre-compiled headers work on the most platforms is to use a (borland and MS-inspired) common header that each CXX in the project includes, and include sequentially all the library headers in a single sequence. Some (esp. some MS, e.g., for sure, MSVC 5.0 and, IIRC, 6.0 as well) C++ compilers precompiled headers feature doesn't work sometimes well in the following include order scenario: a.cpp: aa.h bb.h cc.h b.cpp: aa.h cc.h bb.h even if definition-wise anything seen past the 3 includes expands into the same pre-processed code (with the only differences being extra blanks inserted here and there); for the precompiled headers feature to work it should rather be a.cpp: common.h b.cpp: common.h whereas common.h includes the 3 headers in a single order. All the CPP files that use the precompiled header feature start with #include "common.h" #pragma hdrstop and then whatever includes come after, that don't go to the precompiled header file binary dump. Your change might be incompatible with such platforms. > I can't say if this compiler/linker feature is worth it at all, but > the committed changes will at least hardly make compilation slower, > or rather: a bit slower for some files, and a bit faster for others. > Looks like this will be something to look at again when its time > has come ... >From personal experience, I am wary of using the precompiled headers with gcc at the moment. We don't have a good automated regression test suite for FGFS to make sure nothing is broken. For that reason, I suggest that we don't enable the precompiled headers with GCC at least in the default configure. If you want, I see no harm in adding such option for experimenting. I hope you made some convincing benchmarks to make sure the non-precompiled-headers-enabled GCC setup didn't become significantly longer to compile before committing this change. V. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
