ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Fwd: Re: Storing Generated Code in Git [Was: master 9079e3a:

From: Evan Huus <eapache@xxxxxxxxx>
Date: Mon, 23 Jun 2014 21:17:32 -0400
On Mon, Jun 23, 2014 at 8:42 PM, Anders Broman <a.broman58@xxxxxxxxx> wrote:


---------- Vidarebefordrat meddelande ----------
Från: "Evan Huus" <eapache@xxxxxxxxx>
Datum: 24 jun 2014 00:14
Ämne: Re: [Wireshark-dev] Storing Generated Code in Git [Was: master 9079e3a: Cheat and try to fix the generated file manually.]
Till: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Kopia:

> On Mon, Jun 23, 2014 at 5:32 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>>
>>
>> On Jun 23, 2014, at 2:06 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>>
>> > As far as I can see, the main arguments for storing generated code in git are:
>> > - not all platforms have the tools necessary to generate the code
>> > - generating it can take lots of time
>>
>> I see four different types of people/groups building from source:
>>
>>         1) people who just want the latest Wireshark for a platform for which there are no binary packages;
>>
>>         2) people who want to build the latest Wireshark from source rather than trusting binary packages;
>>
>>         3) people who want to do Wireshark development;
>>
>>         4) people building binary packages for a release.
>>
>> People in group 1 would, presumably, want a source tarball that requires as few tools to build as possible.
>>
>> People in group 2 might, or might not, want that, depending on whether they trust the tools that generate source.
>>
>> People in group 3 might well need to re-build the generated source files, as they might be modifying the source from which they're generated.  They could use a tarball as long as they're only tweaking existing C or C++ code, but if they're adding new code or modifying something that's used to generate other source. they're just like people building from Git.
>>
>> People in group 4 probably could build from a tarball; if they don't want to do that, I have no problem requiring them to have *all* the tools necessary to generate the code or making the process take longer.
>>
>> So perhaps what we should do is:
>>
>>         not check generated code into Git;
>>
>>         put all generated code into the source tarballs.
>
>
> That works fine for me. I have no philosophical objections to putting generated code into a source tarball.

Presumably we should rebuild all the DCERPC files as well at buildtime then?

If that's possible, yes. I don't actually know how to generate them, so I don't know how fast and/or cross-platform it is.