object files from all the source files in the ui directory (but not in
its subdirectories), and link the programs that need it with them.
This cleans things up a little bit, and may also fix the Windows build.
svn path=/trunk/; revision=41061
If 'MANIFEST_INFO_REQUIRED' not defined in config.nmake, don't do 'mt ...' for Wireshark Qt;
Add '*.pdb' to QMAKE_CLEAN;
Fix 'Unescaped backslashes are deprecated' qmake warnings;
Remove "debug" message() statements from QtShark.pro.
svn path=/trunk/; revision=40797
1. Compile and link with (almost exactly) the same options as used
when building Windows Wireshark Gtk.
The options used allow debugging of the exe using Visual Studio exactly
as is done for Wireshark Gtk.
Essentially: configure the "release" version to compile and link with
symbols. (See ui\qt\QtShark for the details).
2. Update QtShark.pro to create a Makefile only for 1 version of Wireshark Qt
which is linked against the "release" Qt libraries.
(IOW: don't create a "debug" Makefile).
3. Remove unused variable assignments from config.pri.
(They can be added back if needed in the future).
svn path=/trunk/; revision=40768
more hard-coded definitions from QtShark.pro. Quote an error message to
fix a Qt Creator complaint.
Add ui\qt\config.pri to the top-level "all" nmake target.
Update README.qt.
svn path=/trunk/; revision=40607
WIRESHARK_RUN_FROM_BUILD_DIRECTORY in your run environment.
On Windows, generate a QMake include file (config.pri) from config.nmake.
svn path=/trunk/; revision=40600
With Subversion 1.7, the working copy metada storage as changed (see
http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng for details).
As a consequence, the file .svn/entries is no more updated and under Windows
the svnversion.h is no more regenerated (unless explicitely removed).
The attached patch fixes this issue so as to also check the .svn/wc.db file
date in the makefile rule.
Note that wc.db file must be checked before entries file as an upgrade of an
existing repository from subversion 1.6 to 1.7 leave an old entries file around
(that is no more updated).
In Makefile.am file, the svnversion.h file generation seems to be
systematically forced. So I guess Linux/Mac boxes are not impacted.
svn path=/trunk/; revision=39910
Makefile.nmake.
Have "clean", "distclean", and "maintainer-clean" in the top-level
Makefile.nmake file clean out the docbook directory.
Add a "docbook" target to the top-level Makefile.nmake file.
svn path=/trunk/; revision=38468
My attachment adds a link to a XSLT file to the preamble of the PDML.
The XSLT will transform the PDML to a HTML page, and the HTML page
features a look similar to Wireshark. See
http://cubic.org/~doj/ebay/a.pdml for an example.
The patch also contains a small perl program which converts the
Wireshark colortable into javascript code which is used in the XSLT
file. If you want to use a different color scheme you would execute the
perl program and insert the generated javascript function into your XSLT
file.
To view the HTML you could either place the PDML and XSLT file on your
webserver and verify that your webserver sends the PDML file as
"text/xml". Then your webbrowser will find the linked XSLT file,
download that as well and convert the PDML to HTML on the fly.
You could also use an XSLT processor like xsltproc to convert the PDML
and XSLT into a static HTML file.
From me:
Minor fixups.
svn path=/trunk/; revision=37298
http://www.apachehaus.com/forum/index.php?action=printpage;topic=143.0
First problem: ZLIB build must be fixed for x64, otherwise there will be one unresolved external symbol later. Quick fix is to open build\win32\build_zlib.bat and insert this at line 51:
set ASM_OPTS=AS=ml64 LOC="-DASMV -DASMINF" OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
(info found in zlib\win32\Makefile.msc) and then open zlib\contrib\masmx64\inffas8664.c and prepend "../../" to four includes at the beginning.
svn path=/trunk/; revision=36616
zlib for GTK hasd this comment:
/* LFS conventions have no meaning on Windows. Looking for feature
* macros like _LARGEFILE64_SOURCE or _FILE_OFFSET_BITS on Windows is
* wrong. So make sure any such macros misguidedly defined by the
* user have no effect. Windows has large file support, but the
* official zlib DLL has not been built to provide the 64-bit offset
* APIs, sigh. So we have just patched out the 64-bit offset API
* from this header file.
*/
svn path=/trunk/; revision=36586
