Re: [Wireshark-dev] Idea for faster dissection on second pas
On 10/10/13 18:22, Evan Huus wrote: It might be simpler and almost as efficient to have recently-successful heuristic dissectors bubble nearer to the top of the list so they are tried sooner. Port/conversation lookups are hash-tables for the most part and likely won't be made noticeably faster by caching. Wouldn't that expose us to the risk that the dissection actually changes on the 2nd pass (because the call order of the heuristics changes)? That would look pretty weird... ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jeff Morriss Sent: den 11 oktober 2013 15:23 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Idea for faster dissection on second pas On 10/10/13 18:22, Evan Huus wrote: >> It might be simpler and almost as efficient to have >> recently-successful heuristic dissectors bubble nearer to the top of >> the list so they are tried sooner. Port/conversation lookups are >> hash-tables for the most part and likely won't be made noticeably >> faster by caching. > >Wouldn't that expose us to the risk that the dissection actually changes on >the 2nd pass (because the call order of the heuristics changes)? >That would look pretty weird... Hmm - yes, another thought is to make a conversation when a heuristic triggers and set the conversation dissector ensuring the same result On the second pass/filtering. Another costly item is col_add_fstr, would it be possible to stack up the col_xx statements and just execute the last one(s) as the lover ones will be overwritten any way. Col_set_fence complicates that further I suppose. Dissectors could be made to only set column info is no subdissector is being called but that may become messy. Regards Anders ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list 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] 1.11.0 release
On 10/09/13 05:47, Bálint Réczey wrote: Hi Gerald, 2013/10/8 Gerald Combs : I've scheduled the release of 1.11.0 for next Tuesday, October 15. Corrections and additions for the release notes are welcome. Unfortunately the transitional state of our UI will be reflected in the release packages: Windows 32-bit: GTK3 and Qt Windows 64-bit: GTK2 and Qt OS X 64-bit: Qt OS X 32-bit: GTK2 Source: GTK3 Hopefully this won't cause too much confusion. I'll probably enable Qt by default in the sources in the next few days, so at least the Windows and source tarball will match. Do you mean enabling Qt and GTK in CMake builds? How about dropping the automake based and nmake based makefile systems and replacing both with CMake? CMake should be available on every platform where Qt builds. I think our CMake stuff has a ways to go before it's ready. Someone already mentioned needing to generate the source tarball but another issue is cross compilation. It looks like CMake supports that from v2.6 but I suppose we'd have to do some work to get it working (and who here actually cross compiles? There are users who do but it seems no developers). ___ Sent via:Wireshark-dev mailing list 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] 1.11.0 release
On 10/09/13 09:15, Bálint Réczey wrote: Hi Guy, 2013/10/9 Guy Harris : I think nowadays almost no one builds Wireshark for their own (apart from Developers) and those who do can easily install the tools for it. Hmmm, I'm not so sure about that statement. I've seen (questions from) plenty of folks using Redhat EL/CentOS who compile their own Wireshark because what comes from the vendor is too old. Maybe things have improved in the Solaris world but last time I tried using a package system I gave up and went back to compiling my own. The package system was pulling in too much junk I didn't want/need, it often just plain didn't work, and after all that the Wireshark package was still too old. Of course things are relative: if you compare the hundreds of thousands of downloads a month of the Windows installers against those who compile their own, yes, "almost no one" compiles their own. ;-) But I suspect among non-Linux *NIX users there are a fair number who still compile their own. ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
On Fri, Oct 11, 2013 at 9:22 AM, Jeff Morriss wrote: > On 10/10/13 18:22, Evan Huus wrote: >> >> It might be simpler and almost as efficient to have >> recently-successful heuristic dissectors bubble nearer to the top of >> the list so they are tried sooner. Port/conversation lookups are >> hash-tables for the most part and likely won't be made noticeably >> faster by caching. > > > Wouldn't that expose us to the risk that the dissection actually changes on > the 2nd pass (because the call order of the heuristics changes)? That would > look pretty weird... Only if two heuristics match the same packet, which is, theoretically, a bug since they can't both be right. ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
On Fri, Oct 11, 2013 at 12:41 AM, Anders Broman wrote: > Evan Huus skrev 2013-10-11 01:51: > > On Thu, Oct 10, 2013 at 6:22 PM, Evan Huus wrote: > > It might be simpler and almost as efficient to have > recently-successful heuristic dissectors bubble nearer to the top of > the list so they are tried sooner. Port/conversation lookups are > hash-tables for the most part and likely won't be made noticeably > faster by caching. > > The attached trivial patch more-or-less implements the above idea. It > isn't easy to bubble dissectors to the very head of the list because > we don't have a modifiable pointer, but it was surprisingly easy to > bubble them to *second* in the list, which should still be a > substantial improvement if there are many expensive heuristics. > > I don't have any long heuristic captures that I can easily time, but > I've run a few short ones and at least it doesn't seem to break > anything. > > Let me know if it helps, > Evan > > In the particular case I'm looking at there is mostly no match in the > heuristics tables except false positives > the same is true for many of the uint table lookups too as there is RTP sent > from a tool simulating many > users with many IP/port combinations making up a huge portion of the > packets. > > Regards > Anders If there are heuristic false positives than there isn't much we can do besides make the individual heuristics better. If the port lookup isn't effective because you know the ports don't line up, you can select the "Try heuristics first" option which should help at least a little. > On Thu, Oct 10, 2013 at 4:22 PM, Anders Broman > wrote: > > Hi, > If we in the UDP/TCP/(SCTP?) dissectors saved next dissector on the first > pas in say per packet data we could avoid > repeated calls to heuristic dissectors and port/conversation lookups making > the second pas faster. > Does any one see any pitfalls with this idea? > > I can think of two ways of implementing it: > - A new entry in pinfo "previous protocol" or something like that. > or > - make dissector_try_uint(), dissector_try_heuristic(), > try_conversation_dissector() return the protocol > or NULL; > > The second is perhaps cleaner but requires more changes or we could make new > functions > dissector_try_heuristic_ret_proto() etc or something like that. > > Comments? > > Regards > Anders > > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
Le vendredi 11 octobre 2013 à 09:22 -0400, Jeff Morriss a écrit : > On 10/10/13 18:22, Evan Huus wrote: > > It might be simpler and almost as efficient to have > > recently-successful heuristic dissectors bubble nearer to the top of > > the list so they are tried sooner. Port/conversation lookups are > > hash-tables for the most part and likely won't be made noticeably > > faster by caching. > > Wouldn't that expose us to the risk that the dissection actually changes > on the 2nd pass (because the call order of the heuristics changes)? > That would look pretty weird... Yes it would. My memories are fuzzy (I did this stuff more than 5 years ago) but 1- you can sort heuristic dissectors by used/unused and keep the relative order. 2 - after the first pass you can stop at the first unused dissector 3 - and/or saved in packet info a boolean for heuristic/non heuristic dissector, it helps a lot for packets without leaf dissectors. I think I also extended conversation semantic for not calling heuristic_try in most cases. Didier ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
On 10/11/13 00:41, Anders Broman wrote: Evan Huus skrev 2013-10-11 01:51: On Thu, Oct 10, 2013 at 6:22 PM, Evan Huus wrote: It might be simpler and almost as efficient to have recently-successful heuristic dissectors bubble nearer to the top of the list so they are tried sooner. Port/conversation lookups are hash-tables for the most part and likely won't be made noticeably faster by caching. The attached trivial patch more-or-less implements the above idea. It isn't easy to bubble dissectors to the very head of the list because we don't have a modifiable pointer, but it was surprisingly easy to bubble them to *second* in the list, which should still be a substantial improvement if there are many expensive heuristics. I don't have any long heuristic captures that I can easily time, but I've run a few short ones and at least it doesn't seem to break anything. Let me know if it helps, Evan In the particular case I'm looking at there is mostly no match in the heuristics tables except false positives the same is true for many of the uint table lookups too as there is RTP sent from a tool simulating many If you're looking mostly at "no match" cases then what about only calling heuristic dissectors that are in the (hopefully stored from the 1st pass) protocols-in-frame list? Maybe it would need to not be a list if we're looking at it that often... ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
On 10/11/13 10:37, Evan Huus wrote: On Fri, Oct 11, 2013 at 9:22 AM, Jeff Morriss wrote: On 10/10/13 18:22, Evan Huus wrote: It might be simpler and almost as efficient to have recently-successful heuristic dissectors bubble nearer to the top of the list so they are tried sooner. Port/conversation lookups are hash-tables for the most part and likely won't be made noticeably faster by caching. Wouldn't that expose us to the risk that the dissection actually changes on the 2nd pass (because the call order of the heuristics changes)? That would look pretty weird... Only if two heuristics match the same packet, which is, theoretically, a bug since they can't both be right. Agreed that it's a bug but I assume it's a fairly common one. Now false positives are only mildly annoying (FAQ: why are my UDP packets showing up as X when they are Y? Answer: Disable protocol X, maybe open a bug to see if we can improve the heuristics); I don't really know what would happen if the the dissection changed from pass to pass. ___ Sent via:Wireshark-dev mailing list 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] Status Cmake Win32 support
Another milestone hit: - Win 32bit: The following executables build and run from the build directory (as well as capture if they should be able to). *: Acutally tested $ ls *exe capinfos.exe* dumpcap.exe mergecap.exe randpkt.exe reordercap.exe tshark.exe* dftest.exeeditcap.exe qtshark.exe* rawshark.exe text2pcap.exe wireshark.exe* TODO - 64bit support - GTK3 detection (i.e. getting pkg-config to work for out setting) - PORTAUDIO support (I probably only need to build it as the nmake setup process does not seem to do that). - Review the cmake and nmake log messages and (try to) fix everything that's not purely informational - Move setup completely out of the nmake Makefiles into the existing or a new setup script. - Maybe a better structured setup with a uniform layout for all packages. - Review by the people who know Windows and the nmake setup (similar to what Guy has been doing for the autotools - cmake sync). - qtshark on win *requires* that gtk includes are present to build: file_dlg_win32.c:#include - abi check: Move abi check operation into a UseABICheck.cmake file and call that from CMakeLists. Then make it work on Win32 in a single place. - API check is missing for all platforms - Determine what else is missing to get rid of the old nmake infrastucture - Are there other platforms that would benefit from something similar to what I did with the setenv.bat script? - Other build platforms (there seems to be at least some interest in VS). Is someone willing to work on some of these items? I'm willing to support anyone who is interested even if that takes me more time than doing it myself. @Balint: Would you be willing to do the abi check cleanup stuff? @Graham: IIRC you already had some setup scripts to replace the old stuff when we talked about this 20 months ago? Ciao Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus Sent: den 11 oktober 2013 16:37 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Idea for faster dissection on second pas On Fri, Oct 11, 2013 at 9:22 AM, Jeff Morriss wrote: >> On 10/10/13 18:22, Evan Huus wrote: >>> >>> It might be simpler and almost as efficient to have >>> recently-successful heuristic dissectors bubble nearer to the top of >>> the list so they are tried sooner. Port/conversation lookups are >>> hash-tables for the most part and likely won't be made noticeably >>> faster by caching. >> >> >> Wouldn't that expose us to the risk that the dissection actually >> changes on the 2nd pass (because the call order of the heuristics >> changes)? That would look pretty weird... > >If there are heuristic false positives than there isn't much we can do besides >make the individual heuristics better. If the port lookup isn't effective >because >you know the ports don't line up, you can select the "Try heuristics >first" option which should help at least a little. Not really as the RTP dissector is weak and defaulted off and I'm only interested in performance improvements at this point. But it brings up a question; some of the heuristic dissectors are for "unusual" protocols and not perfect and some of the "port" dissectors Are registered in the epithermal port range (I think) should we default those to off? > >Only if two heuristics match the same packet, which is, theoretically, a bug >since they can't both be right. Yes but that's the name of the game for heuristics, isn't it? Regards Anders ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list 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] Status Cmake Win32 support
On 11 October 2013 16:09, Joerg Mayer wrote: > Another milestone hit: > > - Win 32bit: The following executables build and run from the build > directory > (as well as capture if they should be able to). *: Acutally tested > $ ls *exe > capinfos.exe* dumpcap.exe mergecap.exe randpkt.exe reordercap.exe > tshark.exe* > dftest.exeeditcap.exe qtshark.exe* rawshark.exe text2pcap.exe > wireshark.exe* > > TODO > > - 64bit support > - GTK3 detection (i.e. getting pkg-config to work for out setting) > - PORTAUDIO support (I probably only need to build it as the nmake > setup process does not seem to do that). > - Review the cmake and nmake log messages and (try to) fix everything > that's not purely informational > > - Move setup completely out of the nmake Makefiles into the existing > or a new setup script. > - Maybe a better structured setup with a uniform layout for all packages. > - Review by the people who know Windows and the nmake setup (similar to > what > Guy has been doing for the autotools - cmake sync). > - qtshark on win *requires* that gtk includes are present to build: > file_dlg_win32.c:#include > - abi check: Move abi check operation into a UseABICheck.cmake file and > call that from CMakeLists. Then make it work on Win32 in a single place. > - API check is missing for all platforms > > - Determine what else is missing to get rid of the old nmake infrastucture > > - Are there other platforms that would benefit from something similar to > what I did with the setenv.bat script? > > - Other build platforms (there seems to be at least some interest in VS). > > Is someone willing to work on some of these items? I'm willing to support > anyone who is interested even if that takes me more time than doing it > myself. > > @Balint: Would you be willing to do the abi check cleanup stuff? > @Graham: IIRC you already had some setup scripts to replace the old > stuff when we talked about this 20 months ago? > > Great stuff Joerg. I think we definitely need CMake to work with VS solutions. I don't see a need to support earlier than VS2010. I'll try the latest stuff when I get home. The stuff I had last year was mainly around removing the need for Cygwin, replacing it with PowerShell, but there was some library download stuff as well. I'm not sure if its still around, I'll have a look tonight. Graham ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
On Fri, Oct 11, 2013 at 11:14 AM, Anders Broman wrote: > Not really as the RTP dissector is weak and defaulted off and I'm only > interested in performance improvements at this point. > But it brings up a question; some of the heuristic dissectors are for > "unusual" protocols and not perfect and some of the "port" dissectors > Are registered in the epithermal port range (I think) should we default those > to off? OK, so I think we have two different concerns here. On one hand we want to try to dissect as much as possible, which implies adding lots of registrations and heuristics. On the other hand we want to dissect as fast as possible, which means removing unnecessary registrations and heuristics. I guess we have to strike a balance, though I'm not sure what that balance should be. I'm *assuming* that the actual thing you're trying to speed up is filtering - that is the most common cause of re-dissection that I'm aware of. Just loading the file only does one pass, so second-pass improvements won't actually help on the initial load. In this case, there might be ways to speed up filtering by caching things in order to completely skip dissection for some packets. I'll have to think on this. If you're trying to speed up something other than filtering, it would help to know what that was :) Cheers, Evan ___ Sent via:Wireshark-dev mailing list 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] Idea for faster dissection on second pas
On Fri, Oct 11, 2013 at 12:37 PM, Evan Huus wrote: > On Fri, Oct 11, 2013 at 11:14 AM, Anders Broman > wrote: >> Not really as the RTP dissector is weak and defaulted off and I'm only >> interested in performance improvements at this point. >> But it brings up a question; some of the heuristic dissectors are for >> "unusual" protocols and not perfect and some of the "port" dissectors >> Are registered in the epithermal port range (I think) should we default >> those to off? > > OK, so I think we have two different concerns here. On one hand we > want to try to dissect as much as possible, which implies adding lots > of registrations and heuristics. On the other hand we want to dissect > as fast as possible, which means removing unnecessary registrations > and heuristics. I guess we have to strike a balance, though I'm not > sure what that balance should be. > > I'm *assuming* that the actual thing you're trying to speed up is > filtering - that is the most common cause of re-dissection that I'm > aware of. Just loading the file only does one pass, so second-pass > improvements won't actually help on the initial load. In this case, > there might be ways to speed up filtering by caching things in order > to completely skip dissection for some packets. I'll have to think on > this. > > If you're trying to speed up something other than filtering, it would > help to know what that was :) Just for fun I hacked together a patch that caches the entire tree generated by each dissection. This uses a frightening amount of memory (an extra ~250MB per 10,000 packets on top of what Wireshark already uses) but makes filtering near-instantaneous for as large a file as I was able to load. Note that the patch is an awful hack, and has several obvious issues. It also doesn't seem to quite work - certain filters returned only a subset of the packets they should have - but that's what you get for a proof-of-concept. If people like the idea I can try and clean it up. Evan cache_all_trees.patch Description: Binary data ___ Sent via:Wireshark-dev mailing list 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] Status Cmake Win32 support
On 10/11/13 8:09 AM, Joerg Mayer wrote: > Another milestone hit: > > - Win 32bit: The following executables build and run from the build directory > (as well as capture if they should be able to). *: Acutally tested > $ ls *exe > capinfos.exe* dumpcap.exe mergecap.exe randpkt.exe reordercap.exe > tshark.exe* > dftest.exeeditcap.exe qtshark.exe* rawshark.exe text2pcap.exe > wireshark.exe* Great! > - qtshark on win *requires* that gtk includes are present to build: > file_dlg_win32.c:#include This should be fixed in r52542-52545. > - Determine what else is missing to get rid of the old nmake infrastucture The NSIS and PortableApps packaging depends on nmake. > - Other build platforms (there seems to be at least some interest in VS). Xcode? > Is someone willing to work on some of these items? I'm willing to support > anyone who is interested even if that takes me more time than doing it > myself. I'll do what I can. ___ Sent via:Wireshark-dev mailing list 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] Status Cmake Win32 support
On Fri, Oct 11, 2013 at 03:48:32PM -0700, Gerald Combs wrote: > > - qtshark on win *requires* that gtk includes are present to build: > > file_dlg_win32.c:#include > > This should be fixed in r52542-52545. Wow, that was fast! > > - Determine what else is missing to get rid of the old nmake infrastucture > > The NSIS and PortableApps packaging depends on nmake. I still have to look at cpack for packaging, but getting it to build a source package was "trivial" when I tried that some years ago - of course not so trivial that I would be able to reproduce it within half an hour... cpack has an NSIS module by the way - but I never packaged more than source. > > - Other build platforms (there seems to be at least some interest in VS). > > Xcode? If someone uses and knows Xcode and wants to work on this: Sure. Ciao Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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] [Wireshark-commits] rev 52556: /trunk/ /trunk/: Makefile.nmake config.nmake
On Fri, Oct 11, 2013 at 11:52:20PM +, ger...@wireshark.org wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52556 > > User: gerald > Date: 2013/10/11 11:52 PM > > Log: > Look for Qt in WIRESHARK_LIB_DIR. Add a conditional check for qmake. > Directory: /trunk/ > ChangesPath Action > +6 -0 Makefile.nmakeModified > +10 -0 config.nmake Modified Which reminds me: For cmake I introduced an environment variable to contain the base location of Qt: QT5_BASE_DIR (see README.cmake). Maybe you can use that as well instead of hard coding it in the makefile? Ciao Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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] 1.11.0 release
On 10/10/13 9:45 AM, Graham Bloice wrote: > On 10 October 2013 01:33, Gerald Combs For people doing development on Windows, would you rather have the Qt > SDK in a central location on your system (I've been using c:\Qt) or in > WIRESHARK_LIB_DIR with everything else (which means taking up a lot of > space if you have multiple WIRESHARK_LIB_DIRs)? > > > I'm the odd one out on this it seems, I have no use for QT5 apart from > Wireshark, so would like them in the WIRESHARK_LIB_DIR. I've only ever > had two lib dirs, one for x86 and one for amd64. It looks like we can support arbitrary locations, at least with the official Qt installer. Qt binaries on Windows have their path hard-coded although it's possible to change them: http://stackoverflow.com/questions/913642/qmake-and-qt-install-prefix-how-can-i-select-a-new-location-for-qt-library The official installer adjusts the prefix automatically when you install in a non-standard location. The packages I built don't and would require manual adjustment. I checked in a change to look for Qt in both C:\Qt and WIRESHARK_LIB_DIR. The next step is to get it installed without too much fuss. I don't think we should add it to the list of libraries handled by "process_libs" since that would mean waiting for half a GB to unpack every time you run "setup". ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
