I thing getting PCHs in sync would be very easy. Moreover, I suggest that even the "highest level" of PCH only include headers frequently added, such as Node, Drawable, NodeCallback, and such (=not too specific ones).
Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ----- "Erik den Dekker" <[email protected]> a écrit : > Different levels of PCH sounds like a good suggestion,... > > When I tried PCH on MSVC about a year ago I tried to take it to the > max and included all used headers to the precompiled header; This > gained the maximum performance for a single compile of the entire > library,… The counter side being that changing a single core osg > header means you have to compile the entire osg again,.. Still, this > could be a valid usage model for people that want to compile a library > from code, but never change a line. It could be the top level of PCH > in your suggestion. > > There's one more thing to it though; precompiled headers should be > kept in sync with the development of the rest of the osg. This may not > be too grave a task. Missing a header in the PCH just means > non-optimal compile performance, and including an extra header that is > no longer available will pop up as a build error as soon as someone > tries to compile with PCH. > > Erik den Dekker > > On 19-01-2010, at 11:33, Sukender wrote: > > > Hi Erik, > > > > You're absolutely right. And what about three levels of PCHs? > > 1. Disable PCH > > 2. Enable PCH - Profile "OSG dev" (only standard includes) > > 3. Enable PCH - Profile "OSG user" (standard includes and base OSG > ones, such as Node) > > It would require a few lines of CMake scripts. > > > > Cheers, > > > > Sukender > > PVLE - Lightweight cross-platform game engine - > http://pvle.sourceforge.net/ > > > > ----- "Erik den Dekker" <[email protected]> a écrit : > > > >> IMHO precompiled headers are only useful if used on headers that > do > >> not or at most rarely change. That leaves little options for which > >> headers to include: > >> > >> Including the standard C/C++ headers in a precompiled header is > >> useful. These should not change anyways. > >> > >> The question if other headers change _rarely_ boils down to your > usage > >> pattern. If you are a OSG library developer you would probably not > >> like it if you have to compile all of the osg libraries if you > change > >> just any one header in the core osg library. This is one of the > >> consequences though if one takes the precompiled headers a step to > >> far, because all .cpp files will depend on the precompiled header, > >> which in its turn depends on the headers it includes. On the other > >> hand, people who just compile the whole of OSG from source once in > a > >> while will probably experience a significant speedup if using > >> precompiled headers. This is one reason it is very important to > make > >> precompiled headers optional using cmake, probably defaulting to > off. > >> > >> Erik den Dekker > >> > >> On 19-01-2010, at 06:37, Ulrich Hertlein wrote: > >> > >>> On 19/01/10 15:21 , Martin Beckett wrote: > >>>> This causes an issue with ShadowVolumeOccluder which defines a > >> std::pair named Point, > >>>> but the precompiled header already includes an osg::Point. > >> ShadowVolumeOccluder has a > >>>> "using namespace osg" which leads to a clash. > >>>> ... > >>>> Would it be a good idea to avoid "using namespace osg" in the > >> headers? > >>> > >>> Absolutely! > >>> > >>> In which OSG include file do you find this? My version of > >> ShadowVolumeOccluder hasn't it > >>> and a grep on svn trunk doesn't show anything too... > >>> > >>> /ulrich > >>> _______________________________________________ > >>> osg-users mailing list > >>> [email protected] > >>> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > >> _______________________________________________ > >> osg-users mailing list > >> [email protected] > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
