Re: Conditional compiles

[Jeff Morriss <jeff.morriss.ws () gmail com>]

I remember getting (infrequent) questions/requests for building Wireshark
without the ability to capture.  Usually the desire seems to come from
corporate IT policies which don't want people capturing corporate traffic
but which need to support users' ability to analyze captures made elsewhere
(test systems or maybe from customers?).

[Of course most of these requests are probably for the Windows version
where you can control the ability to capture by not installing WinPCAP.]

On Tue, Feb 14, 2017 at 5:44 AM, Dario Lombardo <dario.lombardo.ml () gmail com
> wrote:

> 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 () 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 <guy () alum mit edu> wrote:
> >
> > > On Feb 13, 2017, at 4:53 PM, Joerg Mayer <jmayer () 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-request () wireshark org?subject=unsubscribe