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
