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] Handling of generated dissectors

Date: Mon, 7 Oct 2013 08:04:00 -0400 (EDT)
I think the issue is that not all generated dissectors can be generated on all platforms Wireshark supports (for varying reasons).  There were "separate steps" (outside of the Wireshark build process) to generate the PIDL dissector source as well as idl2wrs (GIOP) ones and I thought there were reasons why those "separate steps" weren't in the current build process.
 
I liked Joerg's filename approach, but I would prefer a file prefix that has the generated dissectors show up at the bottom of an alphabetized list (for say Windows Explorer)
 
-----Original Message-----
From: Bálint Réczey <balint@xxxxxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Mon, Oct 7, 2013 4:06 am
Subject: Re: [Wireshark-dev] Handling of generated dissectors

2013/10/7 Joerg Mayer <jmayer@xxxxxxxxx>:
> On Sun, Oct 06, 2013 at 04:27:50PM -0400, Evan Huus wrote:
>> On Sun, Oct 6, 2013 at 4:25 PM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
>> > Hello,
>> >
>> > Matthieu raised an issue that I've seen with asn2wrs generated dissectors
>> > too, just not to the extent of the pidl dissectors. To make it much harder
>> > to miss that the changes we are doing are to generated dissectors I see
>> > two approaches:
>> > - Name the files differently, e.g. prefix with gpacket- instead of packet-,
>> >   so we know when we check that file in that there should be an 
accompanying
>> >   basefile or generator patch.
>> > - Have a checkin script check for the term generated in the first few lines
>> >   and annotate the commit message that a generated file was changed.
>> >
>> > Thoughts?
>>
>> Ideally we wouldn't keep generated files in svn/git at all. We would
>> keep the sources and (if necessary) the generating tool, and we would
>> make generating them part of the build process. This slows down the
>> initial build somewhat, but it makes it absolutely impossible for them
>> to get out of sync.
>
> True. OK, looks like another solution which looks more convincing than
> the ones I proposed.
I support Evan's approach, too. With automake generated Makefiles it was
not a real option since the cross-directory make target dependencies were
not complete, and with the recursive nature of the generated Makefile structure
it was not really manageable easily. I think after switching to CMake and
removing automake build system we could remove all generated files, too.

Cheers,
Balint
___________________________________________________________________________
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