Re: Should we integrate libTrie into our build system?

9 days, no further comments. Merged to trunk, revno 12917.

On Tue, Jun 11, 2013 at 5:53 PM, Kinkie <gkinkie_at_gmail.com> wrote:
>> 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

-- 
    /kinkie