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 <rkn...@gmail.com> 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 <g...@alum.mit.edu> wrote: > >> On Feb 13, 2017, at 4:53 PM, Joerg Mayer <jma...@loplof.de> 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@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=unsubscr >> ibe >> > > > ____________________________________________________________ > _______________ > 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
