Age | Commit message (Collapse) | Author | Files | Lines |
|
Instead of checking for the boolean "FALSE", just set an empty string.
This avoids the need to check for WERROR_COMMON_FLAGS before using it.
The transformation is the same for all files, remove
"if (WERROR_COMMON_FLAGS)" and "endif()", reindent and add quotes (since
we have a string here and not a list).
Modelines have been added where missing.
Change-Id: I0ab05ae507c51fa77336d49a99a226399cc81b92
Reviewed-on: https://code.wireshark.org/review/17997
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Tested-by: Dario Lombardo <lomato@gmail.com>
|
|
Setting our compiler warning flags in CMAKE_C_FLAGS does not allow
using different flags per target.
Allow for that possibility by setting the internal WS_WARNINGS_{C,CXX}_FLAGS
and using the COMPILE_OPTIONS property to set them.
This change is just setting mechanism and there should be no difference
in generated warnings.
The check_X_compiler_flag cmake test is changed to test each flag individually.
We need a list, not a space separated string, and the aggregate test is not
significant.
Change-Id: I59fc5cd7e130c7a5e001c598e3df3e13f83a6a25
Reviewed-on: https://code.wireshark.org/review/17150
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
|
|
This generates a top level target, checkAPI, that is
excluded from the ALL build target, so must be run separately.
On Windows using a Visual Studio generator, call
msbuild /p:Configuration=RelWithDebInfo checkAPI.vcxproj
Change-Id: I44a57c564dcfc75499463b942436f4b920a82478
Reviewed-on: https://code.wireshark.org/review/14873
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
|
|
Smaller epan/CMakeLists.txt is easier to work with and this structure
is well suited to CMake. It should make it easier to manage and configure
each epan module differently if necessary.
Change-Id: Ia649db3b7dcd405aa43dbdba3288699d5e375229
Reviewed-on: https://code.wireshark.org/review/14068
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: João Valverde <j@v6e.pt>
|
|
Change-Id: Ie94d2e9b6b4975d7caec10c3ce472cafe1eefd62
Reviewed-on: https://code.wireshark.org/review/14120
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
The size of some of the wslua source files has grown large, and it's hard
to quickly find things. So split them up based on class name, as much as
seems reasonable. Also have the make-wsluarm.pl Perl script handle this.
Change-Id: Ib495ec5c2a4df90495c0a05504856288a0b09213
Reviewed-on: https://code.wireshark.org/review/9579
Petri-Dish: Hadriel Kaplan <hadrielk@yahoo.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Hadriel Kaplan <hadrielk@yahoo.com>
|
|
Process wslua/CMakeLists.txt using add_subdirectory instead of
include. Generate files in the build directory instead of the source
directory.
Copy lua scripts to DATAFILE_DIR instead of DATAFILE_DIR/lua. That's
where init.lua looks for console.lua.
Always set WIRESHARK_RUN_FROM_BUILD_DIRECTORY when testing. We
presumably want to test our source files and not files which may or
may not be in the system path.
When we're running from the build directory look for lua scripts in both
the Autotools and CMake build locations.
Change-Id: Ic15ab8c58ff1b170d000c9b3e0a329af2ec44b7b
Reviewed-on: https://code.wireshark.org/review/7590
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
make-taps.pl needs to know where to find the source files in order to build
the taps.
This makes the wslua test suite run in autofoo out-of-source-tree builds too.
To make it work with cmake builds requires putting all the epan/wslua/ output
(or at least init.lua) in epan/wslua/ instead of epan/.
Change-Id: I1b3c517f08d3c752ee03cb89482ee4951ceb5bf3
Reviewed-on: https://code.wireshark.org/review/3348
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
|
|
Breaks on windows...
This reverts commit 6b11cd97f2153bb015ade6efd05929999de85457.
Change-Id: I1caf5500da993d7988e09fc0758950469f8252cf
Reviewed-on: https://code.wireshark.org/review/3346
Reviewed-by: Evan Huus <eapache@gmail.com>
|
|
make-taps.pl needs to know where to find the source files otherwise none of
the tap data gets built correctly.
This makes the wslua test suite run in out-of-source-tree builds too.
Change-Id: I059474d90d59e87bd57dba18530a66a927a014cf
Reviewed-on: https://code.wireshark.org/review/3337
Reviewed-by: Evan Huus <eapache@gmail.com>
|
|
The groups are, technically, independent of the notion of a menu, and,
if we have mechanisms by which taps that are not only GUI
toolkit-independent but independent of the *existence* of a GUI can be
registered, they might want to register themselves in a group just in
case they're running in a program that has a GUI.
Also, this might fix the Debian package build.
Change-Id: I29435681e79748fd4f2e0c5ac872cd11f831d172
Reviewed-on: https://code.wireshark.org/review/2830
Reviewed-by: Guy Harris <guy@alum.mit.edu>
|
|
Change-Id: I7bed7f7931845bc41035535cc62e1fe17c71047d
Reviewed-on: https://code.wireshark.org/review/2726
Reviewed-by: Guy Harris <guy@alum.mit.edu>
|
|
(Using sed : sed -i '/^\# \$Id\$/,+1 d') (start with dash)
Change-Id: Ia4b5a6c2302f6a531f6a86c1ec3a2f8205c8c2dd
Reviewed-on: https://code.wireshark.org/review/881
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
This adds new functions to get plugins path info, find out if a directory
exists, make a new one, remove one, etc. It also creates a file environment
for user-supplied Lua scripts, to prevent global variable contamination as
well as supply the script-specific file name. Some other minor cleanup was
done as I found them.
A new testsuite was added to test the existing and new directory functions.
Change-Id: I19bd587b5e8a73d89b8521af73670e023314fb33
Reviewed-on: https://code.wireshark.org/review/832
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
capture file formats.
This enables a Lua script to implement a brand new capture file format reader/writer, so that for example one could write a script to read from vendor-specific "logs" of packets, and show them as normal packets in wireshark.
Change-Id: Id394edfffa94529f39789844c382b7ab6cc2d814
Reviewed-on: https://code.wireshark.org/review/431
Reviewed-by: Hadriel Kaplan <hadrielk@yahoo.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
While Lua's built-in pattern support is ok for simple things, many people end
up wanting a real regex engine. Since Wireshark already includes the GLib
Regex library (a wrapper for PCRE), it makes sense to expose that library to
Lua scripts. This has been done using Lrexlib, one of the most popular regex
bindings for Lua. Lrexlib didn't support binding GLib's Regex in particular -
it does for PCRE but GLib is a different API - so I've done that. A fairly
thorough testsuite came along with that, which has been incorporated into the
wireshark wslua testuites as well in this commit.
Change-Id: I05811d1edf7af8d7c9f4f081de6850f31c0717c7
Reviewed-on: https://code.wireshark.org/review/332
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
Over time the various wslua classes/functions have gotten moldy, with different
ways of doing similar things. Some of it can't be changed without breaking
backwards compatibility for Lua scripts, so I didn't do that. But I did what
I could. The biggest change is a refactoring of how accessors/attributes
are handled in the code, so that most of them work the same way using the
same code.
Specific changes made:
* Added null/expired checking macro to class declarations for many classes
* Removed extraneous pointer/expired checking, since checkFoo() does that already
* Fixed "errors" reported by clang static analyzer; they were false positives, but it was easier to get it to stop complaining by changing the code
* Moved internal wslua functions from wslua_utils.c into a new 'wslua_internals.c' file
* Changed Listener/NSTime/Pinfo/Proto to use a common setter/getter accessor/attribute code model, instead of each of them doing their own
* Fixed some API doc mistakes, mostly around attributes that were documented as read-only but were actually read-write
Change-Id: Idddafc5fbd3545ebff29e063acc767e1c743a1a9
Reviewed-on: https://code.wireshark.org/review/271
Reviewed-by: Evan Huus <eapache@gmail.com>
Tested-by: Evan Huus <eapache@gmail.com>
|
|
This is based on Roberto Ierusalimschy's struct library, along with additional
options based on Flemming Madsen's patch to the lua-users mailing list, and
some changes I made to support 64-bit integer packing/unpacking. Details
are in the top comments for wslua_struct.c. This also includes a test script.
Change-Id: Ifcd0116ba013d5c760927721c8d6e9f28965534b
Reviewed-on: https://code.wireshark.org/review/98
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
|
|
usefulness, working around bug #9162 until Lua 5.3 is released.
The existing Int64 and UInt64 classes provide virtually no
usefullness, other than for creating a string of their value. While
one could then write Lua code to convert the string to Lua numbers and
such, ultimately Lua has no native 64-bit integer support, making such
a task difficult to handle in Lua. This change adds a host of
functions and operators to the existing Int64 (gint64) and UInt64
(guint64) classes, to enable true 64-bit integer support on par with
native Lua numbers.
A test script is also provided, which tests the functions/operators.
Change-Id: I4c5f8f5219b9a88198902283bd32ddf24c346bbe
Reviewed-on: https://code.wireshark.org/review/83
Tested-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Evan Huus <eapache@gmail.com>
|
|
using a Visual Studio solution.
Add CMake properties to group the source files in epan into logical blocks when using a Visual Studio solution.
svn path=/trunk/; revision=52580
|
|
(COPYING will be updated in next commit)
svn path=/trunk/; revision=43536
|
|
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4788
- Compile the python code directly into epan - don't link it in as
a static lib.
- Call make-init-lua.pl with the top level directory instead of the
current directory. Change make-init-lua.pl accordingly.
svn path=/trunk/; revision=33009
|
|
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4788
- Don't build the wslua stuff as a (static) library, build the
stuff directly into epan instead.
The wspython remains to be done.
svn path=/trunk/; revision=32992
|
|
- Add checking for linker flags
- Install plugins with the name including the Wireshark version.
This will make it easier to find matching plugin versions if
files get just copied over.
svn path=/trunk/; revision=32231
|
|
svn path=/trunk/; revision=30852
|
|
Enable it by default.
svn path=/trunk/; revision=30142
|
|
svn path=/trunk/; revision=30093
|
|
svn path=/trunk/; revision=29819
|