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.
