Re: [Wireshark-dev] Improving TCAP session matching
On Sun, Jan 4, 2015 at 12:33 PM, Alexis La Goutte alexis.lagou...@gmail.com wrote: On Sun, Jan 4, 2015 at 1:32 AM, Luke Mewburn l...@mewburn.net wrote: Hi all. I've observed that Wireshark's TCAP session (transaction) matching (enabled with tcap.srt:TRUE) doesn't operate correctly in various cases. I've been working on improving Wireshark's TCAP session handling, and have some questions about the best way to do this as a new contributor to the Wireshark development community. I'm not sure if it's preferable to describe all of the issues in one 'wall of text' email or split up the discussions across multiple messages; I've gone with the former :) Please let me know if the issues should be split out into separate discussions, or if there's a better forum for this (e.g. bugzilla tickets). regards, Luke. Specific fixes -- 1. SCCP GT not set if route-on-SSN. DETAILS:: When sccp.set_addresses is TRUE, the GT isn't used if present when the SCCP route-on-SSN bit is set (i.e not route-on-GT). The GT is still useful for TCAP matching even in this case. PROPOSAL: I've submitted a change for this at: https://code.wireshark.org/review/#/c/6053/ (The second patch attempt is a minor improvement to the wording of the preference after the changes in the original patch). 2. TCAP session matching incomplete. DETAILS: TCAP session matching doesn't cope with TCAP dialogue confirmation. (See TCAP background below for more information about dialogue confirmation). This is because the current implementation uses the destination address for TCAP BEGIN matching (tcaphash_begin_info_key_t.dpc_hash), and origin address for TCAP END matching (tcaphash_end_info_key_t.opc_hash). When TCAP sessions (transactions) aren't correctly matched, then higher level dissectors can mistakenly decode packets part-way through the session because of assumptions about protocol versions (etc). There are existing Wireshark bugs in TCAP (and higher layer) that may be fixed by addressing this PROPOSAL: I have some changes to be submitted for review which resolves this, and greatly improves transaction matching when sccp.set_addresses:TRUE and tcap.srt:TRUE, even when the destination address of the TCAP BEGIN changes as part of dialogue (transaction) confirmation. Future proposals (These could be moved into separate discussions). 1. SCCP addresses not set by default. DETAILS: By default, the SCCP GT is not set as the source and destination addresses for higher layer protocols. The MTP3 (or M3UA) point codes (PCs) are left as these addresses. This can be changed with the preference option sccp.set_addresses. For TCAP transaction matching, the SCCP GT is more correct than the MTP3 PC. PROPOSAL: The sccp.set_addresses default could change to TRUE (and possibly the SUA equivalent, although I haven't any experience with SUA), but I'm not sure what ramifications that this has on protocols other than TCAP that use SCCP. 2. TCAP filters for party addresses. DETAILS: I've experimented with adding new filter nodes to contain the (SCCP GT) addresses of the original calling party (from TCAP BEGIN), the original called party (from TCAP BEGIN), and the confirmed party (from first TCAP CONTINUE or END-after-BEGIN). These depend upon the SCCP addresses set (see above) and the session matching fixed. PROPOSAL: Add new filters. I have a work in progress for this which could be submitted for review. 3. TCAP session matching not enabled by default. DETAILS: The session matching isn't enabled by default. I suspect that this is because it has a performance impact and that it doesn't work reliably (without my fixes :). PROPOSAL: Once the session matching is fixed, it could be enabled by default. 4. TCAP converted to conversation.h (after the latter is enhanced) DETAILS: TCAP uses its own session matching logic. If the standard conversation.h implementation was used, then there may be other benefits such as following conversation flows. I've experimented with this in a private branch, but ran into issues in the current conversation.h implementation that need to be addressed for TCAP. I implemented a new port type - PT_TCAP - to contain the TCAP transaction ID (TID). As described below in TCAP background: - TCAP BEGIN contains a src addr, otid (src port), and dst addr. The dst addr may change in the first CONTINUE. We have to create the conversation with NO_ADDR2 as well as NO_PORT2, which results in the conversation added to conversation_hashtable_no_addr2_or_port2. - TCAP CONTINUE contains src addr, otid, dst addr, dtid. Looking this up with find_conversation() seems to work; if it's the first CONTINUE the conversation is moved from conversation_hashtable_no_addr2_or_port2 to conversation_hashtable_exact. - TCAP END ABORT contains the dst addr, dtid (dst port), and src addr without
Re: [Wireshark-dev] Update Windows Build Instructions
On 4 January 2015 at 21:05, Stephen Fisher sfis...@sdf.org wrote: On Sun, Jan 04, 2015 at 10:08:53AM +, Graham Bloice wrote: Maybe your Win7 SDK came from an earlier install of the Platform SDK? My Win8 32-bit machine at home is a fresh install, so VC 2013 CE is the only VC I've ever installed. The Win7 64-bit install at work install may have had something left over from an older VC install hough. So the Win 8 machine has Win32.Mak in the SDK\7.1A\include dir? If so, it would seem that CE does install the older SDK. I'll try to confirm this later. However, if I ever (or someone else assists) get the Windows CMake build fully operational, all this will go away as we can drop the nmake support. CMake on Windows would still use the Microsot compiler tools, just without the nmake part? CMake can still generate nmake files if you wish, but IMHO the normal route would be to generate VS solution files and then build from the command line with msbuild, or fire up the IDE and build from there. -- Graham Bloice ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On 5 January 2015 at 08:26, Graham Bloice graham.blo...@trihedral.com wrote: On 4 January 2015 at 21:05, Stephen Fisher sfis...@sdf.org wrote: On Sun, Jan 04, 2015 at 10:08:53AM +, Graham Bloice wrote: Maybe your Win7 SDK came from an earlier install of the Platform SDK? My Win8 32-bit machine at home is a fresh install, so VC 2013 CE is the only VC I've ever installed. The Win7 64-bit install at work install may have had something left over from an older VC install hough. So the Win 8 machine has Win32.Mak in the SDK\7.1A\include dir? If so, it would seem that CE does install the older SDK. I'll try to confirm this later. I can confirm that it does. My preferred solution is to copy it into the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include directory, I'll try to update the guide this evening. -- Graham Bloice ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On 5 January 2015 at 17:03, Stephen Fisher sfis...@sdf.org wrote: On Mon, Jan 05, 2015 at 08:26:23AM +, Graham Bloice wrote: CMake can still generate nmake files if you wish, but IMHO the normal route would be to generate VS solution files and then build from the command line with msbuild, or fire up the IDE and build from there. I've always liked the idea of using native build environments on each platform, such as the IDE in VC for Windows. I assume we use nmake files now so we can include makefile.common easily. Is there a straightforward way to (perhaps through a script) build solution files for VC and keep them up-to-date from Makefile.common (or similar file)? Yes, use CMake :-) There are other cross-platform build solutions such as SCons, but it's just as bad as CMake (or maybe worse, I haven't tried anything other than a toy project). Adding a dissector to CMake is as simple as it is for nmake with the bonus that it works for both Windows and Linux (and wherever else CMake is used). Doing anything else with the CMake build system requires a lot of head scratching as getting the required output from the arcane language of CMake files can be a battle. I guess nmake was used in the past as a) it's nearly make, and b) the Visual Studio solution files at the time were horrible undocumented blobs that could only be read by the IDE. Nowadays they're somewhat documented bloated XML blobs that can be built using msbuild (which is quite nice to use). msbuild will also use multiple threads to build so is can be much quicker. The other big advantage of VS solution files is that it should make it easier for folks to use the IDE debugger. I would fire up a CMake build (hint, README.cmake) and try opening the solution in the VS IDE before getting too excited. The IDE still struggles a lot when given lots of projects and files, although when it gets going it's OK for editing. Note that adding source files or making build changes in the IDE will only be temporary as CMake will overwrite them. i.e. CMakeLists.txt (and friends) should be modified for permanent changes. -- Graham Bloice ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On Mon, Jan 05, 2015 at 08:26:23AM +, Graham Bloice wrote: CMake can still generate nmake files if you wish, but IMHO the normal route would be to generate VS solution files and then build from the command line with msbuild, or fire up the IDE and build from there. I've always liked the idea of using native build environments on each platform, such as the IDE in VC for Windows. I assume we use nmake files now so we can include makefile.common easily. Is there a straightforward way to (perhaps through a script) build solution files for VC and keep them up-to-date from Makefile.common (or similar file)? ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On Mon, Jan 05, 2015 at 05:20:27PM +, Graham Bloice wrote: Yes, use CMake :-) There are other cross-platform build solutions such as SCons, but it's just as bad as CMake (or maybe worse, I haven't tried anything other than a toy project). Adding a dissector to CMake is as simple as it is for nmake with the bonus that it works for both Windows and Linux (and wherever else CMake is used). Doing anything else with the CMake build system requires a lot of head scratching as getting the required output from the arcane language of CMake files can be a battle. With such a glowing review as that.. I'm not sure I want to try CMake :) Perhaps it would be better to handle the different platform build methods ourselves. I guess nmake was used in the past as a) it's nearly make, and b) the Visual Studio solution files at the time were horrible undocumented blobs that could only be read by the IDE. Nowadays they're somewhat documented bloated XML blobs that can be built using msbuild (which is quite nice to use) Yuck, XML. msbuild will also use multiple threads to build so is can be much quicker. The other big advantage of VS solution files is that it should make it easier for folks to use the IDE debugger. Indeed. So what about making a script to read in Makefile.common and spitting out those XML files for msbuild? Or update the msbuild so IDE things in those files (if any) aren't reset every time its rebuilt. ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On Mon, Jan 05, 2015 at 03:34:16PM -0500, Ed Beroset wrote: Having been around this particular block a couple of times, yes, CMake at times is a battle, but it's also better than the alternative of producing (and maintaining) multiple mutually incompatible and inevitably arbitrarily different build systems in parallel. The beauty of autoconf/automake on Unix is that it spits out standard MakefileS so that normal users don't have to install a special program just to build the software. I haven't tried Wireshark with CMake yet, but doesn't every user have to install it to build the software? Or can cmake's output be included in source distributions so only developers need it? ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On 6 Jan 2015, at 9:28 am, Graham Bloice graham.blo...@trihedral.com wrote: … CMake does the same job as ac\am but cross platform, and in the same way as ac\am you can't really ship the outputs (makefile or VS solution\vcproj) for use on other systems as they might be configured differently. In my experience, shipping the configure(.sh) and Makefile(s) will work on any Unix system: you don’t need the configure.ac, Makefile.am or autoconf/automake installed in order to configure and build. d signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On 5 January 2015 at 23:20, Stephen Fisher sfis...@sdf.org wrote: On Mon, Jan 05, 2015 at 03:34:16PM -0500, Ed Beroset wrote: Having been around this particular block a couple of times, yes, CMake at times is a battle, but it's also better than the alternative of producing (and maintaining) multiple mutually incompatible and inevitably arbitrarily different build systems in parallel. The beauty of autoconf/automake on Unix is that it spits out standard MakefileS so that normal users don't have to install a special program just to build the software. I haven't tried Wireshark with CMake yet, but doesn't every user have to install it to build the software? Or can cmake's output be included in source distributions so only developers need it? The devastating failure of autoconf\automake (ac\am) is that it isn't cross platform. CMake does the same job as ac\am but cross platform, and in the same way as ac\am you can't really ship the outputs (makefile or VS solution\vcproj) for use on other systems as they might be configured differently. CMake should be at least as easy to install as ac\am on all platforms and considerably easier on Windows (plus it works on Windows with normal Windows build tools). -- Graham Bloice ___ 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
Re: [Wireshark-dev] CMake status
On 5 January 2015 at 20:17, Gerald Combs ger...@wireshark.org wrote: Our CMake environment has been coming along nicely. However, it's still missing several major build targets that are present in the Autotools and Nmake+QMake makefiles: dist. Balint created a script (tools/git-export-release.sh) which runs git archive. I'm not sure how complete it is compared to the current dist output. distcheck. Google turned up a couple of distcheck CMake modules but I'm not sure how applicable they would be to our environment. Having working dist and distcheck targets implies that they would be usable on Windows, which would be nice. packaging (Windows NSIS). If we convert the pile-of-defines in packaging/nsis/Makefile.nmake to a proper NSIS include file it looks like we could migrate the remaining targets pretty easily. Ultimately we might want to use CPack. packaging_papps (PortableApps). Same as the NSIS package. osx-package (.dmg). We need to add support for out-of-tree builds to packaging/macosx/osx-dmg.sh.in. rpm-package (Linux). *Should* be trivial to add. wsug, wsdg, release_notes (Windows). We need to figure out how to migrate the current a2x command (which is an inlined shell script) to something more suitable for CMake. pdb_zip (Windows PDB archive). *Should* be trivial to add. ENABLE_CODE_ANALYSIS (Windows build option). Same. As platforms go, OS X is the closest to completion. If we had a working osx-package target the OS X buildbots could use CMake exclusively. FWIW my current Windows CMake list of tasks to do (in no particular order): 1. Add zlib to build. 2. Add PortAudio to build. 3. Resolve running from build (run) directory. Currently it uses a batch file to modify the path so that all the 3rd party libs (glib etc.) are on the path. I think we need to do the same as the nmaek build and copy the files into the build dir using a script (PowerShell?) to do that work for the CMake build. This will also help when using CMake to create the NSIS package. 4. Fix compile warnings. 5. Fix CMake warnings. 6. Fix WinPcap version number for compile. 7. Get the intermediate build items out of the build dir, e.g. *.lib, *.exp. 8. Get the plugins into the correct subdirectory of the build dir. 9. Get the test executables out of the build dir. 10. Investigate CTest for running the tests. 11. Other stuff I've forgotten. -- Graham Bloice ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On 5 January 2015 at 23:39, Stephen Fisher sfis...@sdf.org wrote: On Tue, Jan 06, 2015 at 09:35:32AM +1000, David Arnold wrote: In my experience, shipping the configure(.sh) and Makefile(s) will work on any Unix system: you don?t need the configure.ac, Makefile.am or autoconf/automake installed in order to configure and build. Right, that's the best part of of autoconf: it generates a shell script called configure that will run on any system without having autoconf installed. Including Windows? -- Graham Bloice Software Developer Trihedral UK Limited ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On Mon, Jan 05, 2015 at 11:46:48PM +, Graham Bloice wrote: On 5 January 2015 at 23:39, Stephen Fisher sfis...@sdf.org wrote: Right, that's the best part of of autoconf: it generates a shell script called configure that will run on any system without having autoconf installed. Including Windows? And that's the worst part of autoconf - no Windows support. At least not without going further into the Cygwin or MinGW world, which gets even further away from native Windows development than we already are. ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On Tue, Jan 06, 2015 at 09:35:32AM +1000, David Arnold wrote: In my experience, shipping the configure(.sh) and Makefile(s) will work on any Unix system: you don?t need the configure.ac, Makefile.am or autoconf/automake installed in order to configure and build. Right, that's the best part of of autoconf: it generates a shell script called configure that will run on any system without having autoconf installed. ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On Mon, Jan 05, 2015 at 03:34:16PM -0500, Ed Beroset wrote: Stephen Fisher wrote: Indeed. So what about making a script to read in Makefile.common and spitting out those XML files for msbuild? Or update the msbuild so IDE things in those files (if any) aren't reset every time its rebuilt. It sounds like reinventing a subset of CMake. Sorry this sounds like a sales pitch -- I've just done this exercise enough times to appreciate that while it's not perfect by a long shot and is maddening when it doesn't work, but even with its flaws, it's better than the alternatives I've found. I just opened Visual Studio and told it to make a New Project from Existing Code (and NOT using an external build system). I know there is a lot more to it because it doesn't know how to link in Qt for example, and numerous other issues I'm sure. But it shows me what the .vcxproj file looks like. It only created one and it includes every source file in every directory. In theory, let's say we finished the project file so it could link Qt and build everything just right... after that, couldn't changes to Makefile.common just be merged into this file with a script? The source files listed look like this: ClCompile Include=epan\crc8-tvb.c / Or am I missing something? ___ 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
Re: [Wireshark-dev] CMake status
On Jan 5, 2015, at 3:11 PM, Graham Bloice graham.blo...@trihedral.com wrote: FWIW my current Windows CMake list of tasks to do (in no particular order): • Add zlib to build. What remains to be done there? The buildbot Win32 and Win64 builds both appear to be picking up zlib. Or do you mean build zlib as part of the build process? • Fix compile warnings. Are there compile warnings we're getting from the CMake build that we're not getting from the nmake build? • Fix CMake warnings. • Fix WinPcap version number for compile. That information isn't available from WinPcap itself. But it's not available from libpcap itself, either, and we don't report it with libpcap; should we just stop reporting it with WinPcap as well? (The version of *pcap with which we're *running* is available with newer versions of libpcap and WinPcap, because I added pcap_lib_version() to libpcap a while ago.) ___ 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
Re: [Wireshark-dev] CMake status
Hi, 2015-01-05 21:17 GMT+01:00 Gerald Combs ger...@wireshark.org: Our CMake environment has been coming along nicely. However, it's still missing several major build targets that are present in the Autotools and Nmake+QMake makefiles: dist. Balint created a script (tools/git-export-release.sh) which runs git archive. I'm not sure how complete it is compared to the current dist output. For my use-case (packaging Wireshark for Debian) it is complete. I think it is better than make dist because the archive does not contain generated files which are not stored in git. Cheers, Balint ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On Mon, Jan 05, 2015 at 06:02:53PM +, Graham Bloice wrote: I don't get your last comment. Unless you're modifying the build system or adding new files, CMake doesn't come into it after the initial solution generation. The solution files automagically rebuild themselves if something in the CMakeLists has changed (i.e. a new file has been added). I see. While not the greatest tool to work with, CMake does do a good job. The dependencies etc. are much better handled than in nmake (minimal rebuilds), it's faster (given more cores), clean is 2 secs, and folks only need to manage one build system on all CMake platforms. Have you tried using CMake for Wireshark on bsd? No, I've only used cmake to build something else in the past. I'll give it a try. ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On 5 January 2015 at 17:35, Stephen Fisher sfis...@sdf.org wrote: On Mon, Jan 05, 2015 at 05:20:27PM +, Graham Bloice wrote: Yes, use CMake :-) There are other cross-platform build solutions such as SCons, but it's just as bad as CMake (or maybe worse, I haven't tried anything other than a toy project). Adding a dissector to CMake is as simple as it is for nmake with the bonus that it works for both Windows and Linux (and wherever else CMake is used). Doing anything else with the CMake build system requires a lot of head scratching as getting the required output from the arcane language of CMake files can be a battle. With such a glowing review as that.. I'm not sure I want to try CMake :) Perhaps it would be better to handle the different platform build methods ourselves. It's the least worst option. It is actively used elsewhere though. We've handled the platform differences in the past by using make and nmake and autofoo and other piles of configuration grief. For Makefile.common, now think of CMakeLists.txt, that bit is very simple. Arguably CMake could be persuaded to read Makefile.common as it's just a list of files. I guess nmake was used in the past as a) it's nearly make, and b) the Visual Studio solution files at the time were horrible undocumented blobs that could only be read by the IDE. Nowadays they're somewhat documented bloated XML blobs that can be built using msbuild (which is quite nice to use) Yuck, XML. Fortunately using CMake means that unless you're modifying the build system you'll never have to look at them. msbuild will also use multiple threads to build so is can be much quicker. The other big advantage of VS solution files is that it should make it easier for folks to use the IDE debugger. Indeed. So what about making a script to read in Makefile.common and spitting out those XML files for msbuild? Or update the msbuild so IDE things in those files (if any) aren't reset every time its rebuilt. Good luck with that, you're just reinventing CMake and Scons and ... . I don't think you're really aware of the scale of the problem. Currently CMake produces 1 solution file and 310 vcxproj files. Sure, some of those .vcxproj files are how CMake checks itself for a rebuild when invoked by msbuild, but a lot of them are necessary. I don't get your last comment. Unless you're modifying the build system or adding new files, CMake doesn't come into it after the initial solution generation. The solution files automagically rebuild themselves if something in the CMakeLists has changed (i.e. a new file has been added). The path is CMakeLists.txt - Wireshark.sln I don't know of any cross platform build system that will then round trip back the way. While not the greatest tool to work with, CMake does do a good job. The dependencies etc. are much better handled than in nmake (minimal rebuilds), it's faster (given more cores), clean is 2 secs, and folks only need to manage one build system on all CMake platforms. Have you tried using CMake for Wireshark on bsd? -- Graham Bloice ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
On 1/5/15 10:02 AM, Graham Bloice wrote: On 5 January 2015 at 17:35, Stephen Fisher sfis...@sdf.org mailto:sfis...@sdf.org wrote: On Mon, Jan 05, 2015 at 05:20:27PM +, Graham Bloice wrote: Yes, use CMake :-) There are other cross-platform build solutions such as SCons, but it's just as bad as CMake (or maybe worse, I haven't tried anything other than a toy project). Adding a dissector to CMake is as simple as it is for nmake with the bonus that it works for both Windows and Linux (and wherever else CMake is used). Doing anything else with the CMake build system requires a lot of head scratching as getting the required output from the arcane language of CMake files can be a battle. With such a glowing review as that.. I'm not sure I want to try CMake :) Perhaps it would be better to handle the different platform build methods ourselves. It's the least worst option. It is actively used elsewhere though. We've handled the platform differences in the past by using make and nmake and autofoo and other piles of configuration grief. Note that Nmake in our case is actually Nmake plus QMake. We could create a ui/qt/Makefile.nmake with the required moc, rcc, uic, and compiler commands but the effort would probably be better spent on bringing the CMake configuration to 100% completion. I'll send a separate email about that shortly. ___ 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
[Wireshark-dev] CMake status
Our CMake environment has been coming along nicely. However, it's still missing several major build targets that are present in the Autotools and Nmake+QMake makefiles: dist. Balint created a script (tools/git-export-release.sh) which runs git archive. I'm not sure how complete it is compared to the current dist output. distcheck. Google turned up a couple of distcheck CMake modules but I'm not sure how applicable they would be to our environment. Having working dist and distcheck targets implies that they would be usable on Windows, which would be nice. packaging (Windows NSIS). If we convert the pile-of-defines in packaging/nsis/Makefile.nmake to a proper NSIS include file it looks like we could migrate the remaining targets pretty easily. Ultimately we might want to use CPack. packaging_papps (PortableApps). Same as the NSIS package. osx-package (.dmg). We need to add support for out-of-tree builds to packaging/macosx/osx-dmg.sh.in. rpm-package (Linux). *Should* be trivial to add. wsug, wsdg, release_notes (Windows). We need to figure out how to migrate the current a2x command (which is an inlined shell script) to something more suitable for CMake. pdb_zip (Windows PDB archive). *Should* be trivial to add. ENABLE_CODE_ANALYSIS (Windows build option). Same. As platforms go, OS X is the closest to completion. If we had a working osx-package target the OS X buildbots could use CMake exclusively. ___ 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
Re: [Wireshark-dev] Update Windows Build Instructions
Stephen Fisher wrote: Yes, use CMake :-) There are other cross-platform build solutions such as SCons, but it's just as bad as CMake (or maybe worse, I haven't tried anything other than a toy project). Adding a dissector to CMake is as simple as it is for nmake with the bonus that it works for both Windows and Linux (and wherever else CMake is used). Doing anything else with the CMake build system requires a lot of head scratching as getting the required output from the arcane language of CMake files can be a battle. With such a glowing review as that.. I'm not sure I want to try CMake :) Perhaps it would be better to handle the different platform build methods ourselves. Having been around this particular block a couple of times, yes, CMake at times is a battle, but it's also better than the alternative of producing (and maintaining) multiple mutually incompatible and inevitably arbitrarily different build systems in parallel. msbuild will also use multiple threads to build so is can be much quicker. The other big advantage of VS solution files is that it should make it easier for folks to use the IDE debugger. Indeed. So what about making a script to read in Makefile.common and spitting out those XML files for msbuild? Or update the msbuild so IDE things in those files (if any) aren't reset every time its rebuilt. It sounds like reinventing a subset of CMake. I've found that for most things (the straightforward part of a makefile that typically makes up 80% of a project's build instructions) CMake works pretty well without a lot of thought. For the other parts, there's usually only pain in figuring it out the first time, but after that, the vagaries of changes to the target systems (e.g. changes to nmake or gnu make or default locations for libraries on BSD, or any of a hundred other details) are all handled by the CMake developers. Sorry this sounds like a sales pitch -- I've just done this exercise enough times to appreciate that while it's not perfect by a long shot and is maddening when it doesn't work, but even with its flaws, it's better than the alternatives I've found. Ed ___ 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
Re: [Wireshark-dev] Protocol stats list in GUI
2015-01-04 20:27 GMT+01:00 Hadriel Kaplan hadri...@yahoo.com: With the addition of another protocol statistic [1], I noticed the list of the various stats is growing long and ugly in the Statistics menu of the GUIs (both GTK and Qt). It's also a jumble of generic things such as 'Flow Graph' and 'Compare...', and protocol-specific stats. And some of those protocol-specific ones are arguably niche protocols - i.e., ones that only a very small population of Wireshark users would ever use. Perhaps the protocol-specific ones should be moved to a Protocol sub-menu of Statistics? Or we could leave HTTP, TCP StreamGraph, and WLAN Traffic at the Statistics menu level, and move the other protocol-specific ones to a Other Protocols sub-menu? And Flow Graph isn't really a statistic - perhaps move it to the Analyze menu? -hadriel [1] for DNS in https://code.wireshark.org/review/#/c/6236/ Hi Hadriel, this makes sense to me. Your proposal to keep at current level the most common protocols and push the other ones in a sub menu seems a rather good tradeoff. BTW it might make sense to move 'Compare' and 'Flow Graph' to the same group as 'Endpoints', 'Packet Length', 'IO Graph', ... Regards, Pascal. ___ 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
