Jaap Keuter wrote:
Hi list,
Going over the tarball on Win32 I've found some cruft in config.nmake.
Hopefully someone with insight can set these straight.
# Support for GTK 2.10 is currently experimental ...
GTK2_INST_VERSION=2.10
PANGO_INST_VERSION=1.14
Is it experimental?
I've changed the comments, GTK2.10 is the mainline since 0.99.5.
WINPCAP_VERSION=3.1
# XXX - what to set for 4.0 beta 1?
It is used to determine which WpdPack (the Winpcap developer pack) is
installed on the developer machine. So a better name would have been
WPDPACK_VERSION to avoid confusion.
However, the setting is a bit odd and caused confusion in the past. This
compile time setting was mistakingly used to determine which functions
are available on the *runtime* machine (which could have a completely
different WinPcap version installed).
The capture related functions must (and will do) determine the installed
WinPcap version dynamically when the winpcap DLL is loaded - so the
above setting is useless and can be removed.
If we need functions from the WinPcap 3.1 or 4.0 API, we should force
our developers to this version instead of adding another confusing
mechanism ;-)
I've completely removed the WINPCAP_VERSION setting (and added a note
that you need at least WpdPack version 3.0).
Weren't we at 4.0? Which may have consequence for this
!IFDEF PCAP_DIR
# Nmake uses carets to escape special characters
WINPCAP_CONFIG=^#define HAVE_LIBPCAP 1
!IF "$(WINPCAP_VERSION)" == "3.0" || "$(WINPCAP_VERSION)" == "3.1"
See above.
And when you make the setup target you get the WpdPack for 3.1
!IFDEF PCAP_DIR
@$(SH) tools\win32-setup.sh --download "$(WIRESHARK_LIBS)" \
. WpdPack_3_1.zip
!ENDIF
As discussed recently, the Wpdpack version used doesn't really matter
(at least for 3.0, 3.1 or 4.0) as there were no API changes we use.
We could switch to WpdPack 4.0 but were not in a hurry about it.
Regards, ULFL