[RfC] Header Dependencies
Juergen Boemmels
Currently there 64 header files in include/parrot. From these 64
header files 36 can be included directly, i.e.
#include <parrot/embed.h>
will compile, but
#include <parrot/chartype.h>
will fail with errors. In the case of chartype this can be easily
fixed [1].
Other headers are a little bit harder.
Would it be a good idea to fix the other headers the same way? This is
not a really hard task. A next step could be not simply include
<parrot/parrot.h>, but only the headers, that are really needed. This
is currently a real pain because some header files have hidden
asumptions to be included only after other header files.
A simple src test can enforce this policy [2].
Comments?
bö
Leopold Toetsch
> Would it be a good idea to fix the other headers the same way?
Cleanup in the headers is for sure a good thing. OTOH I don't know, if
its really useful to only include some headers. Some compilers can AFAIK
precompile header files, so always having just parrot.h is ok.
> b=F6
leo
Dan Sugalski
> Hi,
>
> Currently there 64 header files in include/parrot. From these 64
> header files 36 can be included directly, i.e.
> #include <parrot/embed.h>
> will compile, but
> #include <parrot/chartype.h>
> will fail with errors. In the case of chartype this can be easily
> fixed [1].
> Other headers are a little bit harder.
>
> Would it be a good idea to fix the other headers the same way?
Well... I suppose, though I don't see much point. The headers are the way
they are in part because the interdependencies between the pieces made it
easiest to do it the way that we are. Most (though certainly not all) of
the core source files will just include parrot.h, so I'm not sure how much
work it's worth. (More importantly, I think it'll decay pretty quickly)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Juergen Boemmels
> On Mon, 27 Oct 2003, Juergen Boemmels wrote:
>
> > Hi,
> >
> > Currently there 64 header files in include/parrot. From these 64
> > header files 36 can be included directly, i.e.
> > #include <parrot/embed.h>
> > will compile, but
> > #include <parrot/chartype.h>
> > will fail with errors. In the case of chartype this can be easily
> > fixed [1].
> > Other headers are a little bit harder.
> >
> > Would it be a good idea to fix the other headers the same way?
>
> Well... I suppose, though I don't see much point. The headers are the way
> they are in part because the interdependencies between the pieces made it
> easiest to do it the way that we are.
FreeBSD has problems exactly because of this problem: It needs some
headers before others. What we need at least is respect our own
conventions. I.e. no INTVALs out of PARROT_IN_CORE.
The simplest solution would be: protect all of the headers with
PARROT_IN_CORE.
> Most (though certainly not all) of
> the core source files will just include parrot.h, so I'm not sure how much
> work it's worth.
I don't know if the reason for including parrot.h is only that using
only the minimal set is really hard to get right.
> (More importantly, I think it'll decay pretty quickly)
The attached test would ensure that it won't decay, if this test fails
this is a regression. But I see your point. Keeping MANIFEST up to
date is also a real problem, even though there is a test.
But put it the other way. If we always want to include parrot.h why
are there so many header-files and not only one big parrot.h
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Dan Sugalski
> Dan Sugalski <d...@sidhe.org> writes:
>
> > On Mon, 27 Oct 2003, Juergen Boemmels wrote:
> >
> > > Hi,
> > >
> > > Currently there 64 header files in include/parrot. From these 64
> > > header files 36 can be included directly, i.e.
> > > #include <parrot/embed.h>
> > > will compile, but
> > > #include <parrot/chartype.h>
> > > will fail with errors. In the case of chartype this can be easily
> > > fixed [1].
> > > Other headers are a little bit harder.
> > >
> > > Would it be a good idea to fix the other headers the same way?
> >
> > Well... I suppose, though I don't see much point. The headers are the way
> > they are in part because the interdependencies between the pieces made it
> > easiest to do it the way that we are.
>
> FreeBSD has problems exactly because of this problem: It needs some
> headers before others. What we need at least is respect our own
> conventions. I.e. no INTVALs out of PARROT_IN_CORE.
> The simplest solution would be: protect all of the headers with
> PARROT_IN_CORE.
Or just declare that you shouldn't include parrot.h. :) Which you
shouldn't, really. extend.h and embed.h shouldn't be leaking anything out,
and if they are we need to fix that.
> > Most (though certainly not all) of
> > the core source files will just include parrot.h, so I'm not sure how much
> > work it's worth.
>
> I don't know if the reason for including parrot.h is only that using
> only the minimal set is really hard to get right.
Fair enough, but we don't need to use the minimal set anywhere.
> > (More importantly, I think it'll decay pretty quickly)
>
> The attached test would ensure that it won't decay, if this test fails
> this is a regression. But I see your point. Keeping MANIFEST up to
> date is also a real problem, even though there is a test.
>
> But put it the other way. If we always want to include parrot.h why
> are there so many header-files and not only one big parrot.h
For the same reason there are a lot of .c files and not one big parrot.c.
:)