Re: RFA: abstract C++ ABI dependencies

[Eli Zaretskii <eliz@is.elta.co.il>]

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?