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
