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 <[email protected]> wrote: > On Feb 13, 2017, at 4:53 PM, Joerg Mayer <[email protected]> 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
