[Dario Lombardo <dario.lombardo.ml@xxxxxxxxx>]

Agree. What was the original idea behind having pcap optional? I'm with Guy: is that important to have a non-pcap version of wireshark? If someone is able to clarify a scenario for that, can they share that?

On Tue, Feb 14, 2017 at 10:01 AM, Roland Knall <rknall@xxxxxxxxx> wrote:

There is some misconception about the general approach with this idea. Whilst I applaud any attempt to reduce the number of defines, as it eases the implementation of new features (due to not stumbling over undetected #define issues), I strongly suggest taking a different route here.

HAVE_LIBPCAP not only serves as a check for having libpcap in the first place, but also for changing the UI if it is not there. Which would mean, that putting a small non-functional header-only satisfying version within the repository would lead to versions of Wireshark being build, acting very differently then they are supposed to. For instance, remote capture capabilities are only enabled, if the corresponding function actually exists. Which leads to reduced code and binaries if the function does not. Now putting a small reduced function which only serves to satisfy some header functionality within the repository would bloat up the general binary.

So in conclusion, I vote to not include non-functional code within the source-code just to satisfy #defines

regards

Roland

On Tue, Feb 14, 2017 at 9:48 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Feb 13, 2017, at 4:53 PM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:

> To me it looks like HAVE_LIBPCAP would be a candidate to solve somehow, as it is
> regularly involved when compiles break without this define. Would it maybe make sense
> so include a dummy version inside Wireshark that basically does (mostly) nothing?

To what extent is it important that it be possible to build a version of Wireshark without packet capture capabilities?

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
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