Re: Conditional compilation (debug)

[Michael Mann via Wireshark-dev <wireshark-dev () wireshark org>]

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 <lomato () gmail com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Cc: Michael Mann <mmann78 () 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 <lomato () 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 <rknall () 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.ml () 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.ws () gmail com> wrote:







On Thu, Jul 27, 2017 at 12:34 PM, Dario Lombardo <dario.lombardo.ml () 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-request () 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-request () 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-request () 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-request () wireshark org?subject=unsubscribe