Re: [reSIProcate] gperf updates? Remove some hackery.
Right. I'm good if we just fix the timestamp issue so that is doesn't
require gperf on initial check-out. I don't think the bit of script we
have to do the case insensitive fixup is really causing any headaches.
> -----Original Message-----
> From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf
> Of Jason Fischl
> Sent: Tuesday, October 16, 2007 10:08 AM
> To: Scott Godin
> Cc: Byron Campen; Cullen Jennings; resiprocate-devel resiprocate-devel
> Subject: Re: [reSIProcate] gperf updates? Remove some hackery.
>
> On 10/16/07, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
> > I like Byron's approach - only running gperf if you touch the
headers
> or
> > parameters.
> >
> This is the current approach. gperf doesn't need to be run every time.
> The reason it runs the first time you check out the file is because of
> a problem with the timestamps in svn. This could be fixed in the build
> scripts.
>
> If we make Byron's change, in order to add new headers you will need
> to be on a machine with a recent copy of gperf. Is this really
> necessary?
>
> > Scott
> >
> > > -----Original Message-----
> > > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
> [mailto:resiprocate-
> > > devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Byron Campen
> > > Sent: Tuesday, October 16, 2007 9:00 AM
> > > To: Cullen Jennings
> > > Cc: resiprocate-devel resiprocate-devel; Jason Fischl
> > > Subject: Re: [reSIProcate] gperf updates? Remove some hackery.
> > >
> > > The performance gain would be very slight. I feel that there
> is
> > > enough value in being able to regenerate the table when we add a
> > > header/param/method to make me want to stick with a
gperf-generated
> > > hash function. I don't think that doing it every build is
> worthwhile
> > > though.
> > >
> > > Best regards,
> > > Byron Campen
> > >
> > > >
> > > > 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@xxxxxxxxxxxx>
> > > >>> Date: Fri, 12 Oct 2007 21:21:30
> > > >>> To:Jason Fischl <jason@xxxxxxxxxxxxxxx>
> > > >>> Cc:"Alan Hawrylyshen" <alan@xxxxxxxxxxxx>,
> > "resiprocate-devel
> > > >>> resiprocate-devel" <resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>
> > > >>> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> > > >>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-
> devel
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> resiprocate-devel mailing list
> > > >>> resiprocate-devel@xxxxxxxxxxxxxxx
> > > >>>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> > > >>
> > > >> _______________________________________________
> > > >> resiprocate-devel mailing list
> > > >> resiprocate-devel@xxxxxxxxxxxxxxx
> > > >> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> > >
> > > _______________________________________________
> > > resiprocate-devel mailing list
> > > resiprocate-devel@xxxxxxxxxxxxxxx
> > > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
> >