This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: abstract C++ ABI dependencies
- To: Daniel Berlin <dan at cgsoftware dot com>
- Subject: Re: RFA: abstract C++ ABI dependencies
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Date: Wed, 25 Apr 2001 09:53:01 +0300 (IDT)
- cc: Jim Blandy <jimb at zwingli dot cygnus dot com>, David Taylor <taylor at candd dot org>, gdb-patches at sources dot redhat dot com, Anthony Green <green at redhat dot com>
On 25 Apr 2001, Daniel Berlin wrote:
> Eli Zaretskii <eliz@is.elta.co.il> writes:
>
> > On 24 Apr 2001, Jim Blandy wrote:
> >
> > > > * c-typeprint.c, c-valprint.c, dbxread.c, eval.c, gdbtypes.c,
> > > > jv-typeprint.c, linespec.c, symtab.c, typeprint.c, valops.c:
> > > > #include "cp-abi.h".
> > > >
> > > > For c-valprint.c, eval.c, typeprint.c, and valops.c, it is unclear to
> > > > me why you are including cp-abi.h.
> > >
> > > Because they use functions which used to be declared elsewhere, but
> > > are now declared in cp-abi.h. I've clarified the ChangeLog entry.
> >
> > Isn't it better to put such explanations in the files which include
> > cp-abi.h, rather than in a ChangeLog?
>
> Errr, i don't see any other comments on header includes.
I see _lots_ of them. Two examples (you can see them all with
"grep '#include..*/\*' *.c"):
utils.c:#include "inferior.h" /* for signed_pointer_to_address */
linux-thread.c:#include "gdb_wait.h" /* for WUNTRACED and __WCLONE flags */
But even if these comments were not present, that doesn't mean they
shouldn't be there.
> Why would you list the reasons for including a given header?
Because people who read the code afterwards might ask themselves why
was that header included, if the name of the header doesn't make that
obvious.
This seems especially important since lately some of the maintainers are
actively terying to remove unneeded headers in order to minimize
dependencies and slash the build time.
> If you want to know what's in the header, and you can't tell from the
> top of the header itself, or the filename of the header, well, then,
> there's probably something else wrong.
Maybe something _is_ wrong. If so, the code should be reworked
accordingly.
However, if, after all the deliberations, it is decided to leave the
header inclusion, and that header's name does not explain why it is
needed, like in the case in point (see David's question), then I think
the explanation should be in the code, not in the ChangeLog.
In other words, if there were no reason to have an explanation, why would
Jim feel he should provide one on the ChangeLog?