[reSIProcate] gperf updates? Remove some hackery.

[Cullen Jennings]

I always been a fan of removing the gperf dependency all together. If  
you are willing to use just a little bit more memory for the tables,  
it is pretty trivial to get more or less any reasonable hash function  
to not collide for some size table. I suspect that making the table  
that much larger would be a drop in the bucket of overall memory use  
in resip.

On Oct 12, 2007, at 7:56 PM, Byron Campen wrote:

> 	I think Jason is saying that most embedded systems won't have gperf
> 3. I'm saying that the answer is to not build new hash functions
> using the regular build. Put it aside as a separate script that can
> be run independent of the regular build, and just have all the
> generated files live in the repository. This would remove a build
> dependency that is continually giving newcomers grief (always a good
> thing), cut down on the complexity of the build system a little (also
> good), and probably help performance a tiny bit (I imagine gperf will
> generate slightly better code than our hacked-up scripts will).
>
> Best regards,
> Byron Campen
>
>> I must be missing something. What does changing gperf have to do
>> with embedded builds?
>>
>> Thanks
>> A
>>
>> -----Original Message-----
>> From: Byron Campen <bcampen at estacado.net>
>> Date: Fri, 12 Oct 2007 21:21:30
>> To:Jason Fischl <jason at counterpath.com>
>> Cc:"Alan Hawrylyshen" <alan at polyphase.ca>,       "resiprocate-devel
>> resiprocate-devel" <resiprocate-devel at list.resiprocate.org>
>> Subject: Re: [reSIProcate] gperf updates? Remove some hackery.
>>
>> 	I would like to point out that generating fresh hash functions on
>> every build is of limited value, especially considering the hoops you
>> have to jump through to add a method/header/parameter anyway.
>>
>> Best regards,
>> Byron Campen
>>
>>> The only thing i'll point out is that this will break the build on
>>> lots of embedded systems. What does it really buy us?
>>>
>>> On 10/9/07, Byron Campen <bcampen at estacado.net> wrote:
>>>> 	I'm all for it.
>>>>
>>>> Best regards,
>>>> Byron Campen
>>>>
>>>>> I've noticed that the newer versions of gperf permit case-
>>>>> insensitive
>>>>> hashes to be generated. I find this oddly satisfying given that  
>>>>> the
>>>>> GNU/FSF position on this previously was 'over my dead body'.
>>>>>
>>>>> What are peoples' feelings around updating our build process to
>>>>> leverage gperf 3.X and remove the hackery that edits the output of
>>>>> the hash function generators?
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Alan
>>>>>
>>>>> Alan Hawrylyshen
>>>>> a l a n a t p o l y p h a s e d o t c a
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> resiprocate-devel mailing list
>>>>> resiprocate-devel at resiprocate.org
>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>
>>>>
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel