hi!
with cws pchfi04 it was planned to use non-dummy precompiled header in a
number of modules that should benefit most. the precompiled_<module>.hxx
were created with the simplistic approach to include all used header
found in the module and strip those that hinder compilation.
unfortunately, when taking a closer look, this isn't sufficient.
e.g. in sd/source/core/drawdoc.cxx you find these lines:
...
#define ITEMID_SCRIPTSPACE EE_PARA_ASIANCJKSPACING
#include <svx/scriptspaceitem.hxx>
...
this include uses the define to pass the default parameter to
SvxScriptSpaceItem( sal_Bool bOn = sal_False,
const sal_uInt16 nId = ITEMID_SCRIPTSPACE );
so, why doesn't this fail in the precompile_sd.hxx? for whatever reason,
this define is set in svx/inc/eeitemid.hxx (in this case to the same
value by chance) and due to the internal include guards,
scriptspaceitem.hxx isn't revisited with the define set in the cxx file.
in svx there are about 70 hxx files like this and there is also one
known in sfx2 (srchitem.hxx).
this example shows there are still errors lurking that cannot be
detected while building. and even when removing "context sensitive"
includes in precompiled_<module>.hxx, the next codechange may bring them
back indirect.
another point that worries me is the different list of includes
depending on using pch or not.
a very simple result is that developers using pch will break the build
of those not using pch without being able to notice if new includes are
required that already reside in the precompiled file. any c/c++ expert
may be able to construct more elaborate error cases caused by this...
simply removing the guards in the current precompile_<module>.hxx to
align the includes again seems to be no option as it slows down
compiltation without pch by round about a factor of four compared to the
compile times today (may be even more on windows...).
at the moment, i'm not sure that this "all you can include" approach
will come to an happy end. maybe cautiously selecting a set of includes
for the precompile hxx would be more appropriate regarding the two
issues i currently see...
tschau...
ause
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
