Re: confoig.h squid.h design

Alex Rousskov wrote:
> 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.
>

Right. To be blunt and as simple as possible.

Where does "squid_types.h" get included when every file in squid needs
"uint32_t" ??
THEN, where does "squid_mswin.h" get included for the same type
definition in windows?

(NP: mswin (rightly!) setups more than types...)

Methinks squid_mswin.h goes in config.h and squid_types.h goes in
squid_mswin.h (and other OS-specifics)

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

That 'but' is one thing we are trying to do away with. It's presence in
FreeBSD and other sources has been a headache more than once for Squid.

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

Okay.

>> 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.

Okay.

Amos

-- 
Please use Squid 2.6.STABLE19 or 3.0.STABLE4