It looks like we can't put "COPYCMD=/Y" in config.nmake and expect nmake
to do the right thing. Add a comment, and set COPYCMD explicitly in the
root Makefile.nmake. The rest of the occurrences of xcopy will have to
be taken care of at some point.
svn path=/trunk/; revision=15840
to fix compilation under Windows NT. This should fix bug 403.
The changes were made using "find . -name Makefile.nmake | xargs perl
-pi.bak -e 's: /y::i'". They appear to work under XP, but if anything
broke I blame Larry Wall.
svn path=/trunk/; revision=15710
Makefile.nmake instead of doing our own XCOPYing. Use the "clean-deps"
target when we're done instead of leaving DLLs lying around.
Normalize the use of underscores vs hyphens in the "clean-deps" target.
svn path=/trunk/; revision=15704
- not only look for the cygwin tools, but also check the MSVC tools required like cl.exe, link.exe and nmake.exe
- I don't know why we should use /usr/bin/find but simply find, check for it instead. If there's a reason to use /usr/bin/find, we should use $(FIND) instead but I currently don't see a reason for this
svn path=/trunk/; revision=15220
in the plugins subdirectory. This target will copy all plugins to plugins/$(VERSION), thus (t)ethereal will
find and load the plugins when called from within the source tree.
call this target from the main nmake makefile after
installing other dependencies. call it from the nmake makefile
in the doc subdirectory before calling "tethereal -G".
This way "tethereal -G" will recognize the filterable
fields from the plugins, too.
svn path=/trunk/; revision=14284
This target will copy all files, mainly dlls, which
are necessary to run (t)ethereal to the source tree.
After copying all necessary dlls to the source tree,
you can run (t)ethereal directly from the source tree.
svn path=/trunk/; revision=14259
filter after installing the filter.
Set HAVE_PCAP_LIB_VERSION if we're building with WinPcap 3.1; it's not
present in earlier versions, but is present in current 3.1 betas.
Check HAVE_PCAP_LIB_VERSION when building capture-wpcap.c.
svn path=/trunk/; revision=13872
files. Do this with GENERATED_HEADER_FILES, GENERATED_C_FILES, and
GENERATED_FILES macros in Makefile.common files, along the lines of what
wiretap/Makefile.common has.
Clean up "*~" files with "make clean" rather than only "make distclean"
in some additional places.
Add "maintainer-clean" rules to the Makefile.nmake files, paralelling
the ones in the automake-generated Makefile.in files, using the
GENERATED_FILES macros from Makefile.common files. In some cases, move
the cleanup of files from "make distclean" to "make maintainer-clean",
and in other cases, put in a comment indicating why we're not doing that
(because some files that are distributed in the source tarballs, namely
Flex output, were built with a UN*X Flex and won't compile on Windows,
so we get rid of them with "make distclean" so you can clean up stuff
that *has* to be re-generated for Windows).
Clean up some *CLEANFILES definitions - get rid of ones that no longer
apply as files were moved or that add to the definition a name that's
already there.
svn path=/trunk/; revision=13402
object code for libethereal.dll isn't generated by the
makefile in /trunk.
Having no code in /trunk linked into libethereal.dll
anymore, the definition of the macro _NEED_VAR_IMPORT_
can be moved from various source files in /trunk to /trunk/Makefile.nmake .
So do that, too.
svn path=/trunk/; revision=13389
Cygwin this has the side effect of making the Windows "find" command appear
first in the path instead of Cygwin's "find" command. Call /usr/bin/find
explicitly in win32-setup.sh.
svn path=/trunk/; revision=12639
Also add support for pcap_datalink_name_to_val(), and arrange that we
properly define HAVE_PCAP_DATALINK_NAME_TO_VAL and
HAVE_PCAP_DATALINK_VAL_TO_NAME for MSVC++ builds.
svn path=/trunk/; revision=12073
Many people have recently reported many problems with the nmake build
process. It seems that these problems come from using
epan/makefile.nmake to compile the DISSECTOR_SUPPORT_SOURCES which are
located in /trunk.
Nmake from MSVC6 puts the object code of the DISSECTOR_SUPPORT_SOURCES
in /epan although Nmake expects the object code in /trunk when it
checkes dependencies. Thus DISSECTOR_SUPPORT_OBJECTS are built every
time even when they are already there.
Nmake Version 1.5 (MSVC 2003 Toolkit) puts the object code of the
DISSECTOR_SUPPORT_SOURCES in /trunk instead.
This makes it impossible to use epan/makefile.nmake for compiling the
DISSECTOR_SUPPORT_SOURCES and to make it work for both versions of nmake.
We have to use /trunk/makefile.nmake for compiling the
DISSECTOR_SUPPORT_SOURCES to solve these issues.
It should also be possible to build ethereal without libethereal.dll again.
Once we have moved all DISSECTOR_SUPPORT_SOURCES into a subdirectory of
epan we can get rid of this patchwork in the nmake makefiles.
svn path=/trunk/; revision=11562