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
