Re: [MERGE] config.h renaming to squid.h

On Sat, Jan 21, 2012 at 12:20 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> 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!

Either this or not having it build on windows ;)
All in all, it took significantly less than I'd expect.

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

Thanks for spotting it. Fixed.

>>   * 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? Perhaps all general
> documentation should tell developers to include squid.h, leaving
> squid-old.h to special cases only?

Adding a phrase by which I define it deprecated. Part of the work I'm
doing (e.g. StatHist refactor etc.) is about getting stuff out of
protos.h, globals.h etc. squid-old.h will take its turn eventually.

>> -#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?

IMVHO there is no need to, at this time.
New bundle attached.

-- 
    /kinkie