dlinkNodeNew is my fault - I was aiming for what is possibly a little *too* much flexability. I believe the memPool stuff is nearly
in a position to be moved to lib given the recent work on it though...
Rob
----- Original Message -----
From: "KevinL" <darius@bofh.net.au>
To: <squid-dev@squid-cache.org>
Sent: Saturday, January 27, 2001 1:28 AM
Subject: dlink*
>
> Heya,
>
> Those watching cvs will have seen I'm trying to get an sfs_test program
> compiling. It lets me tinker with the fs code - mount, write, read, umount.
> Unfortunately, said sfs code is using dlink* functions, and they appear to
> exist in tools.c/tools.o, the linking of which becomes painful fast, as it
> requires a bunch of other things, quickly spiralling up to almost all of src/.
>
> Is there any problem with splitting dlink* functions off into lib/ somewhere,
> and compiling them into libmiscutils instead? They appear to be reasonably
> standalone (with the exception of memPoolCreate used in dlinkNodeNew - I'd be
> tempted to leave that where it is *frown*)
>
> Or is there a better idea than this?
>
> KevinL
>
>
Received on Fri Jan 26 2001 - 07:18:23 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:25 MST