< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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