RE: [XaraXtreme-dev] includes, XARLIB and camtypes.h

["Gerry Iles" <GerryI@xxxxxxxx>]

Well, the reason for the conditional in camtypes.h is so that XarLib can
use the same source as XaraLX without having to ship all of the headers
that aren't actually needed by the code that is included in XarLib.  If
we change the headers so that all the content is conditional then the
XarLib source package would still need to include lots of files that are
effectively blank.

Is the conditional bit itself causing trouble for your script or is this
more a potential problem that might crop up in the future?  Do you have
some specific changes in mind that you think might break XarLib?

The source for XarLib consists of a subset of the XaraLX files
(camtypes.h, some from wxOil and some from Kernel) and a few other files
in another subfolder that appears before the others in the include order
(some are replacements for XaraLX files that would require too much
conditional code and some are new files that provide the XarLib API).

It is possible to include alternate versions of headers in this other
subfolder (as is currently done with camelot.h and ensure.h) but I don't
really want to include a whole spate of empty replacement headers.

I don't think there is going to be a big problem assuming those headers
that are part of XarLib are included outside the conditional bit in
camtypes.h so I'll move those newly added includes that are part of
XarLib to outside the #ifndef so that source files that are part of
XarLib that you have removed includes from (and moved them to
camtypes.h) still build as part of XarLib.

Gerry

 
-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 08 June 2006 23:25
To: xara-dev
Cc: Alex Bligh
Subject: [XaraXtreme-dev] includes, XARLIB and camtypes.h

[Gerry especially]

I have an automatic mechanism of stripping include files that are
already included (directly or indirectly) in camtypes.h out from
files that are not themselves part of camtypes. It gives a
build speed improvement for a complete rebuild of between
10% and 20% (down from approx 2 mins 30 to 2 mins 05). I suspect
the improvement will be greater the less powerful the machine
is.

It removes 3,926 unnecessary instances of #include.

My problem is with XARLIB. Currently the contents of camtypes.h
depend on whether XARLIB is defined. If I remove ALL the files,
then conceivably those files could be used by a cpp in XARLIB
and the #includes will need to be added manually
However, I can't blindly stick in the includes back into
camtypes.h when XARLIB is defined as they might not even
compile.

Would a reasonably approach be for me to remove the
"#ifndef XARLIB" in camtypes.h, and for any headers that
you don't want (Gerry) because it doesn't compile, #ifndef
the whole header out inside the header itself?

On a separate note, I have restored some disabled bits
to camtypes.h which should speed things up, and added
a few more files that were included by over a hundred
object files. This should optimize speed for those
compiling with pch's (sorry Mr Build Server and anyone
on gcc<3.4).

I've made substantial progress disentangling include spaghetti
but there's not a great deal more I can do without serious
surgery (i.e. actually changing the to use pointers rather
than included members, etc.)

Alex