On 08/30/2012 04:31 AM, Evan Huus wrote:
On Wed, Aug 29, 2012 at 7:28 PM, Anders Broman<a.broman@xxxxxxxxxxxx> 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.
Thanks,
Jaap
