Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] master 9079e3a: Cheat and try to fix the
Den 24 jun 2014 16:54 skrev "Alexis La Goutte" <alexis.lagoutte@xxxxxxxxx>:
>
> On Mon, Jun 23, 2014 at 10:32 PM, Pascal Quantin
> <pascal.quantin@xxxxxxxxx> wrote:
> > Hi all,
> >
> > Le 23/06/2014 22:22, Jakub Zawadzki a écrit :
> >> Hello Evan,
> >>
> >> On Mon, Jun 23, 2014 at 02:10:13PM -0400, Evan Huus wrote:
> >>> Storing generated files in source control makes maintenance and patch
> >>> review much harder and puts extra requirements on us to keep things in
> >>> sync. I'd rather the computer do the extra work :)
> >> But in the same time, we can have 3rd party library, like nghttp2[1] (12KLOC) put into git.
> >>
> >> This is already more than 30 commits behind nghttp2/lib git HEAD,
> >> nor README.nghttp2 is updated about recent fixes in this forked code.
> > FYI the only fixes done on top of those listed in README.nghttp2 should
> > be casts to ensure proper compilation on Windows. AFAIK Alexis intends
> > to submit those changes upstream. And we are only interested by the
> > decompression part of the library.
> > We decided to add nghttp2 to Wireshark source code (for now) as it is
> > not available to all platforms yet. We might remove it in the future and
> > use 3rd party packages if required. I still consider this as a WIP and
> > nothing is frozen. But at least it provides decompression functionality
> > for the still moving HTTP2 drafts.
>
> Thanks Pascal for help ;-)
> All my patch is include in upstream (only some specify cast or
> Wc++compact warning...)
> I have a my own branch on github with ntghttp and wireshark stuff (
> https://github.com/alagoutte/nghttp2/commits/wireshark (may be need a
> git push from my dev machine)
>
> I have found a another lib (with less code...) with only http2 huffman
> decode but no time to try
> https://code.google.com/p/lightweight-http2-huffman-decoder/
There might be huffman code in sigcomp.c or udvm. c
>
>
> >
> >>
> >>> We store C files and require a compiler, where we could just store the
> >>> compiled .o files in source control. To me this is much the same thing.
> >> Great to know.
> > IMHO, storing source files (even if those are the output of generation
> > tools) can hardly be compared as storing object files.
> >>
> >>> Balint and Jörg and I discussed that we would eventually like to remove the
> >>> ASN.1 generated source from git as well, and make that a standard part of
> >>> the build process.
> >> I am happy to hear this, please do.
> >> For sure you want also do this for X11 dissector, which for rebuilt only requires
> >> downloading mesa sources.
> > While I understand the objective, we must keep in mind that removing the
> > ASN.1 generated files will increase by a non negligible time the first
> > build time (which means all buildbot builds). It represents severals
> > minutes on my machine....
> >
> > Regards,
> > Pascal.
> >
> > ___________________________________________________________________________
> > Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> > Archives: http://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> > mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
