Re: confoig.h squid.h design

Alex Rousskov wrote:
> On Sat, 2008-04-26 at 00:33 +1200, Amos Jeffries wrote:
>
>> So why not put that in compat/?
>> Well, I'm imagining the compat/ parent directory itself having stuff
>> like the MD5.h specific small-scale compat which components might need
>> to share, but not the whole of squid. The semi-critical bits as I think
>> of them.
>> compat/includes and compat/lib you mentioned in your plans as being
>> propose for autoconf to perform complete squid-wide replacement of
>> missing header files or functions.
>> I thought of bits as the equivalent for manual developer use instead of
>> cluttering those up again.
>
> The critical versus semi-critical (or manual versus automated?)

I wasn't so much thinking of automatic. Thats configurable in auto-tools
as you pointed out earlier. And they are written to prevent major stuff-ups.

> distinction between what should go into compat/ and what should go into
> compat/bits is still not clear to me, but I will try to figure it out as
> we add stuff. If you are confident we need this, let's not waste time on
> this discussion. Just correct me if I start putting stuff in the wrong
> directory. With bzr, it should not be difficult to move it.

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.

The problem I see with 1 is keeping non-experts fingers out of the few
critical files (remember me +MD5). But 2 has the problem of some files
being duplicated from other projects sources (SNMP).

>
>>> What will happen is that you will have to place two-line wrappers in
>>> compat/ so that the rest of the code can get access to some of the stuff
>>> in compat/bits/. That's not a big deal.
>> May not be a big deal but I don't understand you.
>> Please explain by what you mean by having to us two-line wrappers. And
>> what form they would need to take (#if ... #endif ?? or makefile: if ...
>> fi ??).
>
> I was talking about include files. See /usr/include/c
> ++/*/map, /usr/include/c++/*/string and other GCC STL files for examples
> of such wrappers. Those STL header wrappers have some logic/need in
> them; hopefully ours will too.

This is similar to what I'm proposing. But with a different background
cause (see the above example)
I notice they also use the 'bits' pseudonym for their second-level.

Amos

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