On Thu, Aug 30, 2012 at 6:21 PM, Jaap Keuter <jaap.keu...@xs4all.nl> wrote: > On 08/30/2012 04:31 AM, Evan Huus wrote: >> >> On Wed, Aug 29, 2012 at 7:28 PM, Anders Broman<a.bro...@bredband.net> >> wrote: >>> >>> Jeff Morriss skrev 2012-08-30 00:29: >>> >>>> Evan Huus wrote: >>>>>> >>>>>> >>>>>> I'm not 100% convinced either way, but I have to admit I do like >>>>>> having >>>>>> all >>>>>> the dissectors in the same directory. "make -j 40" (on my 32-vCPU >>>>>> SPARC) >>>>>> works better that way ;-). >>>>> >>>>> >>>>> >>>>> I'm pretty sure an autotools-generated Makefile will already recurse >>>>> to fill the given job-count as long as there aren't any weird >>>>> dependencies in place, so it shouldn't make any difference. Can't >>>>> speak for cmake or windows builds. >>>> >>>> >>>> >>>> Only if all the files are in one Makefile (e.g., >>>> epan/dissectors/Makefile). If each subdir has its own Makefile then >>>> each >>>> directory is processed one at a time (in my experience). >>>> >>>>>> More seriously, I imagine I'd find it easier to >>>>>> do: >>>>>> >>>>>> vi epan/dissectors/packet-xmpp<tab><tab> >>>>>> >>>>>> instead of: >>>>>> >>>>>> vi >>>>>> >>>>>> >>>>>> epan/dissectors/packet-xmpp<tab><tab>[1]^H^H^H^H^H^H^H^H^H^H^Hxmpp<tab>/<tab><tab> >>>>>> >>>>>> [1] insert grumpy remark here >>>>> >>>>> >>>>> >>>>> Fair enough. So another tweak to the suggested naming: >>>>> packet-xmpp/xmpp-whatever.c >>>> >>>> >>>> >>>> In fact taking your suggestion of removing "packet-" from all the file >>>> names would also achieve the same thing. >>>> >>> I'm not particularly fond of the idea - just being conservative perhaps; >>> but how many subdirectories >>> are acceptable before it gets out of hand - 1000, one for every protocol >>> in >>> WS or a smaller number ;-) >> >> >> I expect most dissectors will stay in the root of epan/dissectors/. My >> understanding is that this would only be in a few select cases >> (bluetooth and xmpp are the ones that come to mind) where there is a >> clear logical grouping of a large number (16 for bluetooth, 14 for >> xmpp) of files. It makes sense to put them in their own folder. >> >> I just gave epan/dissectors/ a quick scan. Here are the other large >> groupings that immediately stand out: >> - aim (23 files) >> - dcerpc (111 files) >> - gsm (23 files) >> - h### (33 files) (is there a better generic name for this category?) >> - ipmi (12 files) >> - smb (15 files) >> - zbee (14 files) >> >> There are lots and lots of smaller groups of 4-5 files, but I wouldn't >> expect them to get their own folder. >> >> More input is always welcome :) >> >> Evan > > > Oke, I'm still missing the quantitative rationale here. When I'm looking at > the number of dissector files in trunk I get: > > jaap@phoenix:~/src/wireshark/trunk/epan/dissectors$ ls -1 | grep ^packet | > wc -l > 1501 > > Your list gives 23+111+23+33+12+15+14 = 231, that's a mere 15%. > > That doesn't really alleviate the problem.
I don't think the intent in the original proposal was that this would magically reduce epan/dissectors/ to a fraction of its original size, but 15% is a non-trivial improvement. Also, my list was only a quick scan based on file-name similarities. I'm sure there are other logical groups that aren't as obvious simply because the file names are inconsistent. ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe