[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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

Gerry,

--On 09 June 2006 17:57 +0100 Gerry Iles <GerryI@xxxxxxxx> wrote:


I haven't really done any chopping yet.  I've only changed camtypes.h so
that the files required by XarLib build using the reduced header set in
XarLib.  This required a few files to be directly included where they
were being pulled in indirectly via headers that aren't in XarLib.


OK


I think we're talking at cross-purposes here.  I'm fairly sure that
ccfile.h didn't used to be included in camtypes.h.  After your changes
it was included indirectly via camfiltr.h and the direct includes of it
in cpp files were removed.


I put camfiltr.h in because it was included (directly or indirectly)
by over a hundred files. I'm pretty sure ccfile.h *was* actually
already included (or I would have included it specifically - as
I took the top few n files, and it can't be included in fewer
files than camfiltr.h as camfiltr.h included it) - also I don't
remember doing it. But no matter.

I'm presuming XarLib does use CCFile, right?


 I have added ccfile.h directly to camtypes.h
because camfiltr.h isn't part of XarLib.


Yes, fine.


 What I am asking is whether
you think I should now remove the include of ccfile.h in camfiltr.h as
it is not necessary anymore?


Ah. I see. Without XARLIB defined, there is not really an issue either
way (though a commented out version would be preferred to no include
at all, or someone will only stick it in. When building the pch it
won't be included because gcc will remember the file has been
included before. When building any other file, only the pch fill
be included. And nothing will include camfiltr.h directly.

With XARLIB defined, camfiltr.h isn't going to be included anyway,
so again, it doesn't much matter.

Now, given there is (hopefully) a reason why camfiltr.h includes
ccfile.h (e.g. because it has a member CCFile variable, as opposed
to just a pointer). It will be much easier to get the include
dependencies right (i.e. not rely on file ordering in camtypes.h)
if we keep these things in.


If you think it should be removed then I will do so as part of the
spaghetti chopping once I have some more RAM in this machine.


I can't see much point. It's like saying "DocRect.h" need not include
"DocCoord.h". Well, technically, that's true because we know doccoord.h is
never included from anywhere directly, it's only ever included from pch
files. But it means we need to start worrying about the /order/ of the
included files in camtypes.h. Because of gcc's duplicate file inclusion
detection (Mart says it works when building stuff that doesn't have the
file included /by/ a .pch) it can't noticeably add to build time. And
anyway, if you are rebuilding camtypes.h.gch, the time to build that
particular file is the last thing to worry about.

In all this I'm presuming not only is camfiltr.h not in the Xarlib
pch, but actually isn't any Xarlib stuff at all - i.e. there isn't
some other file, not in the main build svn, which includes camfiltr.h
which would then include ccfile.h which is already in the pch. Even
if this was the case, to be honest I'd say "well put camfiltr.h
in the pch then".

Alex