Re: Should we integrate libTrie into our build system?

On 11/06/2013 8:12 p.m., Kinkie wrote:
> Hi all,
> the attached patch removes libTrie's own autotools instrumentation,
> and leverages squid's instead.
> The aim is to improve portability, the nice-to-have side-effect is
> cutting compile time.
> (note: my test build on ubuntu roaring is currently failing due to
> issues highlighted by clang's static code checker elsewhere), I'll
> cover it separately.
>
> Comments?

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.

* 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.

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

* libTrie/test missing TestHeaders.am include

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

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.
  + libTrie/test/* files can stay where they are and reference the
includes as above with "libTrie/" base path.

* 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.

Amos

> On Sun, Jun 9, 2013 at 11:41 PM, Robert Collins
> <robertc_at_robertcollins.net> wrote:
>> On 10 June 2013 08:40, Kinkie <gkinkie_at_gmail.com> wrote:
>>> Hi all,
>>> while attempting to increase portability to recent clang releases, I
>>> noticed that libTrie hasn't benefited from the portability work that
>>> was done in the past few years.
>>>
>>> I can see three ways to move forward:
>>> 1- replicate these changes into libTrie
>>> 2- change libTrie to piggyback squid's configuration variables
>>> 3- fully integrate libTrie into squid's build system. Unless Robert
>>> knows otherwise, squid is the only user of this library..
>> I'm not aware fo it being shipped/used separately. Probably want to
>> replace it by now, must be a tuned equivalent somewhere :)
>>
>> -Rob
>>> Comments?
>>>
>>> --
>>> /kinkie
>>
>>
>> --
>> Robert Collins <rbtcollins_at_hp.com>
>> Distinguished Technologist
>> HP Cloud Services
>
>
Received on Tue Jun 11 2013 - 09:50:59 MDT