On 21/01/2012 12:20 p.m., Alex Rousskov wrote:
On 01/20/2012 12:02 PM, Kinkie wrote:
As discussed today with Amos, here's the merge bundle for:
- renaming squid.h to squid-old.h
- renaming config.h to squid.h
- reconnecting things
This ipatch will avoid name clashes on Windows (and probably also
MacOS) between config.h and various Config.h files scattered in the
source-factor'ed subtrees (case insensitivity..)
Glad you are fixing this!
-squid.h begins by including config.h to prepare for its sub-includes and
definitions.
+squid.h begins by including squid.h to prepare for its sub-includes and
definitions.
Please remove the above squid.h repetition and check the whole paragraph
for similar problems.
* If your code requires any symbols from here you should be importing
- * config.h/squid.h at the top line of your .cc or .h file.
+ * squid.h/squid-old.h at the top line of your .cc or .h file.
Should we encourage squid-old.h import?
No.
Perhaps all general
documentation should tell developers to include squid.h, leaving
squid-old.h to special cases only?
Yes.
The scripts/source-maintenance.sh script needs its mentions of config.h
swapped for squid.h and reviewed
-#include "config.h"
+#include "squid.h"
I wonder whether the new squid.h should be moved into a directory and/or
included using a directory name, to minimize the chances that we would
have to go through this again in a few years?
You mean squid/squid.h or such?
Its current form is dictated (loosely) by its exitence in the code
bundle include/ directory for use everywhere within the bundled sources.
We could include it with (#include "include/squid.h") but makes it a bit
of ugly look.
config.h is just a common include point for various defines, autotools
includes and the compat library. If we have to go through this again any
time soon something has gone wrong.
Amos
