Re: confoig.h squid.h design

On Sun, 2008-04-27 at 03:14 +1200, Amos Jeffries wrote:

> Any .h files included by config.h need to be wrapped in a very specific
> way. Including config.h in an apparent circular include OUTSIDE their
> normal wrappers.
> This permits them to be both self-consistent, and dependency tested
> without screwing up the order of their definitions relative to config.h
> itself.
> I guess we could do away with the sub-directory and use the whole
> compat/ directory as include through config.h.
>
> I was just hoping that wiser heads could chime in with a better way, or
> show that it wasn't necessary. ... While I was writing this reply up I
> thought of the alternative below.
>
> Here is the case that started me on this:
>
>
> config.h:
> #if CONF
> ... blah config types needs ...
> #include "squid_type.h"
> .. blah setup depending on types ...
> #endif
>
>
> squid_types.h:
> #include "config.h"
> #if TYPES
> .. blah type config ...
> #endif
>
>
> In order for types to compile for testing it must include config.h for
> the (...blah config types needs...) bit. BUT also MUST NOT define
> (...blah setup depending on types...) until types has been defined.
>
>
> The only reasonable alternative I see is;
>
> adding at least one more header and breaking the final section
> proposed for config.h (a list of sub-includes) into that instead of
> config.h itself.
> (in this case the new header would become squid.h instead of renaming
> of config.h)
>
>
> and a lot of unreasonable ones:
> A nest of #if statements around everything. That would need to be
> maintained even more carefully than the proposed setup.
>
> OR a single compat header with everything in it (effectively the
> current squid.h plus a lot more).
>
> OR complicating the .h testing with a lot more exceptions. And I plan
> on removing the two it currently has.
>
> OR including each of the compat .h files at each .cc
>
>
>
> I guess what I'm looking for is a vote of preference:
>
> 1) special structure of config.h with protection wrapping on compat files.
>
> 2) breaking the existing compat and config files up into maybe a lot
> of smaller units so they can be fully self-consistent and non-circular
> in their includes.

I have to admit I have trouble understanding the above, including the
choices, but I think we should use a simple strategy:

1) config.h includes the autogenerated configuration file and does
virtually nothing else

2) squid.h includes config.h and does virtually nothing else.

3) any other .h file must be self-contained but may assume that squid.h
was included before that .h file.

4) any .cc file must include squid.h first.

> The problem I see with 1 is keeping non-experts fingers out of the few
> critical files (remember me +MD5).

I would not try to solve this small problem by source tree design. This
is what source code comments, documentation, and code review are for.

HTH,

Alex.
Received on Sun Apr 27 2008 - 16:29:48 MDT