Joerg Mayer wrote:
When the packages containing the libs are present, but the development
stuff is missing, configure fails. The proper way to handle this should
be to disable this feature and continue.
Well, maybe. Often people don't realize that they need the configure stuff.
My inclination might be to:
by default, support the feature only if the libraries are present;
have a --with-XXX option (perhaps it already does), and if it's
specified, fail if the libraries *and* development stuff aren't present;
allow the corresponding --without-XXX option to disable the feature
even if the libraries and development stuff are present.
Compiling gives a lot of warnings, the list is attached.
The signedness warnings might not be important - it's all the PDP-11's
fault, with its byte load instructions being signed by default, thus
resulting in "char" being signed by default on PDP-11 C and, for
compatibility, on most other C implementations, which is inconvenient
for non-ASCII text. Ultimately we need to handle strings better, so
that we can deal both with different encodings of strings in packets and
with GTK+ 1.2[.x] font sets (GTK+ 2.x, and other GUI toolkits we'd be
likely to use, can handle Unicode) and locales with non-UTF-8 encodings.
The *other* warnings are more important, e.g. casting away constness
(which in almost all cases can and should be avoided, and in many other
cases can be fixed by making pointer arguments not used to modify the
argument const pointer arguments), lack of declaration of functions
before use (declaring before use means that type checking can be done on
argument lists), non-ISO-C90 warnings (not all compilers used to compile
Ethereal are as forgiving as GCC, although some warnings come from GLib
macros and there's nothing you can do about them), etc..
