Storing Generated Code in Git [Was: master 9079e3a: Cheat and try to fix the generated file manually.]

[Evan Huus <eapache () gmail com>]

Perhaps this is a discussion we should have had at Sharkfest, but it's come
up now. Oh well.

My objections to generated code in git are two-fold: practical and
philosophical.

Practically, it's painful to have to run make twice to test ASN.1 changes.
It's painful to review diffs full of #line changes in generated code. It's
painful to be debugging something and realize that the last time somebody
changed the template file they forgot to regenerate the dissector.
Generated code also complicates the use of tools like ctags because all the
ASN.1 functions end up with two definitions - one in the original template,
and one in the generated code.

Philosophically, generated C code is not "source". Ideally we store only
"source" in git, and the build process turns that source into usable
binaries, libraries, etc. Most of our source already goes through an
intermediate step (.o file, on *nix at least) before reaching its final
form. Whether it goes through a second intermediate step as a .c file is
irrelevant to me, because that step is intermediary. I don't want to have
to care about it unless I'm actually working on the build system.

---

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

Both of these are valid points, in a general sense. I don't think either of
them are particularly strong with respect to ASN.1 specifically, but there
is a very good argument to be made for keeping the X11 dissector in git
(for example).

---

There are also cases like lemon, where we don't store the generated files
but we store a fork of the entire generating program itself. Ideally we
wouldn't do this either, but there are many fewer practical pain points
with this approach.

---

Are there any general arguments I've missed? Other opinions, or
perspectives?

Evan

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe