The issue is that extcaps are started before preferences are read/loaded. I believe this was discovered when talking able enabling/disabling extcaps through preferences to help startup times (because many users don't use extcaps) I thought about maybe creating an "early preferences" grouping (reuse preference architecture, but for things needed a lot closer to startup), but it hasn't materialized. -----Original Message----- From: Dario Lombardo <lom...@gmail.com> To: Developer support list for Wireshark <wireshark-dev@wireshark.org> Cc: Michael Mann <mman...@netscape.net> Sent: Sat, Jul 29, 2017 4:36 pm Subject: Re: Conditional compilation (debug)
I mean preferences. On Saturday, July 29, 2017, Michael Mann via Wireshark-dev <wireshark-dev@wireshark.org> wrote: Define "config". Do you mean preferences (which I thought we already had)? Or build configuration? (or "other") -----Original Message----- From: Dario Lombardo <lom...@gmail.com> To: Developer support list for Wireshark <wireshark-dev@wireshark.org> Sent: Sat, Jul 29, 2017 11:23 am Subject: Re: [Wireshark-dev] Conditional compilation (debug) We don't have an extcap branch in the config, do we? Wouldn't be worth to have one for such a configurations? On Friday, July 28, 2017, Roland Knall <rkn...@gmail.com> wrote: I would not distinguish between self-builds and buildbot builds. There are extcap developers out there, who use the released Wireshark version to develop extcap interfaces and also would benefit greatly from using such debug scenarios. And I would not want to tell them to explicitly build a development version, just to develop an extcap. More specifically, if they develop the extcap with Python, they may not even be able easily to build Wireshark at all. On the other side, not every dev wants to see the debug functionality for extcap, so having those users stuck with debug output may also not be advisable. Last, some issues can come up, especially with printf stuff, where debug outputs actually hinder development. If you have a timing-constraint related bug, it may not appear in a debug version, because the debug code may slow down the utility enough, so that the issue may not appear, but it would appear in the release version. Not every developer thinks of such a thing and would end up hunting bugs they cannot see. So, please do integrate such a feature in the normal code, but make it configurable via preference for instance, to enable/disable the functionality. Do not distinguish, if it is a dev-build or release build cheers Roland On Thu, Jul 27, 2017 at 10:11 PM, Dario Lombardo <dario.lombardo...@gmail.com> wrote: I was thinking to something like CMAKE_BUILD_TYPE (Debug/Release), but I'm not sure it fits the purpose and anyway it is cmake specific. The goal is: I want to make the debug of the interaction between ui and extcaps easier. For that I'd like to use some debug entries in the extcap interface dialog. Those flags are mostly developer-oriented, then I'd like to get rid of them in release builds, although I don't know if wireshark release builds and others differ in some way. I'd like something that mimics assert() behavior, if I'm not mistaken. On Thu, Jul 27, 2017 at 6:58 PM, Jeff Morriss <jeff.morriss...@gmail.com> wrote: On Thu, Jul 27, 2017 at 12:34 PM, Dario Lombardo <dario.lombardo...@gmail.com> wrote: Hi I'd like to add some code that appears only in development builds of wireshark. Is there some define that helps me understand if I am in such a case, both in autotools and cmake? Define "development build." Do you mean 2.3.x or 2.5.x or do you mean anything not built on a buildbot? For the latter we frequently just check if we're running in a build directory (there's also an environment variable for that). ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Naima is online. ___________________________________________________________________________Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives: https://www.wireshark.org/lists/wireshark-devUnsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Naima is online.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
