Re: /bzr/squid3/trunk/ r9575: Do not redefine max(). compat/compat_shared.h:135 is the location of the

Henrik Nordstrom wrote:
> sön 2009-03-15 klockan 21:07 +1300 skrev Amos Jeffries:
>
>> Um, IMO these helper redefinitions we do not need.
>> There are conceptual problems still with not being able to simply go to
>> helper directory and 'make install' as long as they need libcompat from
>> a higher level directory.
>
> Always been like that. Don't see why it's a problem. Many helpers
> already depend on libmiscutil.
>
> To reinstall only a single helper the standard procedure is:
>
> make all
> cd helpsers/.../...
> make install
>
> For a faster build you can
> make -C lib
> make -C compat
> make -C helper/.../...
> make -C helper/.../... install

Okay, with both Alex and Henriks assurance that its not a problem to
care about ....

If anyone sees duplicate code provided *anywhere* in squid which is also
provided exactly as-is by the libcompat, please remove the duplicate
outside libcompat (that includes #include <xxx> statements).
If its only similarly duplicate check carefully if the user can use the
'standard' libcompat version instead.

>
> One question on this however.. why is compat placed outside lib? What
> makes compat different from lib? A lot of what is found in lib is either
> just OS glue or independent of Squid in general.
>

compat is outside lib because lib is only being partially migrated into
compat.

The rest of lib which isn't glue is planned for migrated to contrib or
somesuch at a later date. Having compat separate keeps the boundaries
cleaner at this early stage of migration and lets us keep libmisc until
its fully cleaned out.

Also, libmisc has a C-interface while libcompat is C++ interface. My
next update to libcompat is seeing a bunch of helpers convert to build
with C++.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
   Current Beta Squid 3.1.0.6