Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] master 9079e3a: Cheat and try to fix the

From: Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>
Date: Tue, 24 Jun 2014 16:54:25 +0200
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/


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