Re: Should we integrate libTrie into our build system?

> PS. Like robert said, if there is a fast tuned alternative we want to be
> testing the speed and possibly replacing this with an alternative.

This topic spawned a separate thread, let's keep it there.

> * the change to lib/Makefile.am is wrong. libTrie is only used by ESI, so
> does not need to be built and linked unless ESI is enabled.

Ok, reverted.

> * in lib/libTrie/test/Makefile.am the $(top_builddir) is now needing
> adjusting to add the "/lib/libTrie" path.

Ok

> * libTrie/test missing TestHeaders.am include

Added.

> * scripts/source-maintenance exception for libTrie when checking for squid.h
> can be removed by this patch.

Ok, thanks. Also done for bootstrap.sh.

> Provided we are building it only as a convenience library now and not as a
> separate package the whole library structure can change for simpler #include
> usage:
> * the files in libTrie/include and libTrie/src can be shuffled up one level
> into libTrie/
> + #include references updated to "libTrie/X.h" through both library and ESI
> component code.

Done

> + libTrie/test/* files can stay where they are and reference the includes
> as above with "libTrie/" base path.

Done

> * when the above are done all libTrie uses of INCLUDES can be dropped
> entirely. Just include src/Common.am into the remaining libTrie Makefile.am
> instead.

Done.

Revised patch attached. Also available as lp:~kinkie/squid/libtrie-refactor