directory in which global data files are stored. If an installed binary
is being run, that's the correct directory for them; if a build-tree
binary is being run, the "manuf" file will be there, and you can put
other data files there as well, if necessary.
Do the same with plugins, except that, if there's no
"plugins\\{version}" subdirectory of that directory, fall back on the
default installation directory, so you at least have a place where you
can put plugins for use by build-tree binaries. (Should we, instead,
have the Windows build procedure create a subdirectory of the "plugins"
source directory, with the plugin version number as its name, and copy
the plugins there, so you'd use the build-tree plugin binaries?)
Move "test_for_directory()" out of "util.c" and into
"epan/filesystem.c", with the other file system access portability
wrappers and convenience routines. Fix "util.h" not to declare it - or
other routines moved to "epan/filesystem.c" a while ago.
svn path=/trunk/; revision=3858
and never was - there's only an Ethereal-wide "enable name resolution"
preference. Name it just "name_resolve".
Replace all tests of "g_resolving_actif" with tests of
"prefs.name_resolv", and replace all code that sets "g_resolving_actif"
with code that sets "prefs.name_resolv", so that the setting of
"prefs.name_resolv" actually affects whether names are resolved or not.
svn path=/trunk/; revision=3300
and "u_char" aren't declared in <sys/types.h> in Win32, you have to
include <winsock.h>, which is a pain.
Throw in some "const"s while we're at it.
svn path=/trunk/; revision=3240
"globals.h" file to "epan/resolv.h", as it's exported by
"epan/resolv.c", have files that use "g_resolving_actif" include
"resolv.h", and don't have "epan/resolv.c" include "globals.h" so that
it doesn't drag in, for example, headers that, in turn, drag in GTK+
headers.
svn path=/trunk/; revision=2517
file, rather than the top-level Ethereal configuration file, check for
"inet_aton()", "inet_pton()", and "inet_ntop()". Then make its
Makefile.am include the appropriate object files if necessary.
Otherwise, they don't get built and put into libethereal, and therefore
attempts to link with anything in libethereal that uses them fail on
platforms that lack ethem, causing the build to fail.
That means a bunch of things need to be fixed to cope with libethereal
having its own "config.h" file; this means removing the include of
"config.h" from some libethereal header files. Move the definitions of
the path names used only by "resolv.c" to "resolv.c" from "resolv.h" (so
"resolv.h" doesn't need "config.h", define HAVE_PLUGINS in the configure
script (so we don't have to include it in "plugins.h" to check whether
HAVE_DLFCN_H is defined).
Unfortunately, stuff outside libethereal needs to know PLUGIN_DIR; for
now, define that in the top-level configuration file, and have Ethereal
and Tethereal pass it as an argument to "epan_init()" - that should be
cleaned up at some point.
Remove from the top-level configure script checks for things used only
in libethereal.
svn path=/trunk/; revision=2498
Guy Harris