I got a bit carried away in suggesting that libui, libdfilter, and
libftypes all be shared libraries, I withdrawl that part of my suggestion.
I have noted that wiretap currently seems to stand on it's own. The
dependencies in libethereal appear at a cursory examination to be
packet.c: depends on
packet-atalk.h
packet-frame.h
packet-ipv6.h
packet-sna.h
packet-vines.h
packet-osi.h
resolv.c: depends on
packet-ipv6.h
packet-ipx.h
proto.c: depends on
packet-ipv6.h
register.h
I suspect that all of the dependencies on packet-*.h are simply
utility functions related to those protocols and that those utility
functions can be abstracted out into an libethereal itself (
util-ipv6.{c,h} etc. )
The dependency on register.h is a little more basic, as it
speaks to how we handle dissectors. I've considered a number of
possible ways around this problem.
1) Convert the existing dissector base into individual plugins.
This has the advantage of being highly
modular. It has the disadvantage that we are likely
to run into some unhappy dependency issues that will have
to be resolved along the way, it will be a fair bit of
work, and that in almost any large undertaking there
is the risk of unpleasant unforseen consequences.
2) Convert the existing dissctor base into one jumbo plugin.
I don't see anything in the plugin mechanism that would
prevent the existing dissectors from being
rolled into one big plugin that registers all of the
protocols contained in it when plugin_init is called and
registers all of it's handoffs when it's plugin_reg_handoff is
called.
This has the advantage of being quick and easy. It has the
disadvantage of being ugly as hell and extremely non-modular.
3) Start with solution 2, as it will allow us to cleave libethereal
off now ( at least internally to ethereal) and make it a shared
object. Proceed to move towards 1, as it is the right thing
to do in the long run.
I favor the third way, but am quite interested in other opinions.
Ed
On Mon, 19 Mar 2001, Gilbert Ramirez wrote:
> Ed Warnicke wrote:
> >
> > Is there a reason that libethereal, libdfilter, libftypes, libwiretap,
> > and libui aren't being built and installed as shared libraries?
> >
> > I know there is some mention of doing this in the epan directory,
> > but I was wondering if there was a good reason this hadn't been done yet.
> >
> > Ed
>
>
> There's no reason not to ship wiretap as a shared libary.
> Libethereal, however, still needs a little cleanup. There are some
> functions
> that it uses that are in the dissectors code. I tried it one time, but
> I don't remember exactly which functions. It had to do with address
> types
> used in packet.c that exist in the dissectors.
>
> Hmm, maybe some better documentation on how to use wiretap would be
> good.
> Once its a shared library, there's a better chance that other projects
> will
> want to use it.
>
> libdfilter and libftypes were meant to always be archives. When
> libethereal
> is a shared library, libftypes and libdfilter will be archives of PIC
> objects
> that are linked into libethereal.
>
> Libui was also never meant to be a shared library.
>
> --gilbert
>