X-Git-Url: http://git.efficios.com/?a=blobdiff_plain;f=CONTRIBUTING.adoc;h=72434e89346dc4ef7dcd15e306ae095898a87794;hb=74f4949e3f9bfc452f48cd9d9fec1dccbb1f0404;hp=c800b70e21837bee74b3af45a5531f95e742610b;hpb=cd4aac1ead64d006fea9b9ff3d8306c0a6dd4c56;p=babeltrace.git diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc index c800b70e..72434e89 100644 --- a/CONTRIBUTING.adoc +++ b/CONTRIBUTING.adoc @@ -246,7 +246,7 @@ can find the cause of a bug faster. While <> when placing _DEBUG_ to _FATAL_ logging statements, you should liberally instrument your -Babeltrace module with _VERBOSE_ logging statements to help future you +Babeltrace module with _TRACE_ logging statements to help future you and other developers understand what's happening at run time. @@ -295,7 +295,7 @@ hidden symbol which is the library's current log level before including This header offers the <>. -`"plugins/comp-logging.h"`:: +`"logging/comp-logging.h"`:: Specific internal header to use within a component class. + This header offers the <> and <> to learn how to be able to use the following macros. -`+BT_LOGV("format string", ...)+`:: - Generic verbose logging statement. +`+BT_LOGT("format string", ...)+`:: + Generic trace logging statement. `+BT_LOGD("format string", ...)+`:: Generic debug logging statement. @@ -493,8 +496,8 @@ file (generic)>> to learn how to be able to use the following macros. `+BT_LOGF("format string", ...)+`:: Generic fatal logging statement. -`+BT_LOGV_STR("preformatted string")+`:: - Generic preformatted string verbose logging statement. +`+BT_LOGT_STR("preformatted string")+`:: + Generic preformatted string trace logging statement. `+BT_LOGD_STR("preformatted string")+`:: Generic preformatted string debug logging statement. @@ -511,8 +514,8 @@ file (generic)>> to learn how to be able to use the following macros. `+BT_LOGF_STR("preformatted string")+`:: Generic preformatted string fatal logging statement. -`+BT_LOGV_MEM(data_ptr, data_size, "format string", ...)+`:: - Generic memory verbose logging statement. +`+BT_LOGT_MEM(data_ptr, data_size, "format string", ...)+`:: + Generic memory trace logging statement. `+BT_LOGD_MEM(data_ptr, data_size, "format string", ...)+`:: Generic memory debug logging statement. @@ -529,8 +532,8 @@ file (generic)>> to learn how to be able to use the following macros. `+BT_LOGF_MEM(data_ptr, data_size, "format string", ...)+`:: Generic memory fatal logging statement. -`+BT_LOGV_ERRNO("initial message", "format string", ...)+`:: - Generic `errno` string verbose logging statement. +`+BT_LOGT_ERRNO("initial message", "format string", ...)+`:: + Generic `errno` string trace logging statement. `+BT_LOGD_ERRNO("initial message", "format string", ...)+`:: Generic `errno` string debug logging statement. @@ -562,8 +565,8 @@ learn how to be able to use the following macros. The library logging statement macros are named `+BT_LIB_LOG*()+` instead of `+BT_LOG*()+`: -`+BT_LIB_LOGV("format string", ...)+`:: - Library verbose logging statement. +`+BT_LIB_LOGT("format string", ...)+`:: + Library trace logging statement. `+BT_LIB_LOGD("format string", ...)+`:: Library debug logging statement. @@ -580,6 +583,18 @@ of `+BT_LOG*()+`: `+BT_LIB_LOGF("format string", ...)+`:: Library fatal logging statement. +`+BT_LIB_LOGW_APPEND_CAUSE("format string", ...)+`:: + Library warning logging statement, and unconditional error cause + appending. + +`+BT_LIB_LOGE_APPEND_CAUSE("format string", ...)+`:: + Library error logging statement, and unconditional error cause + appending. + +`+BT_LIB_LOGF_APPEND_CAUSE("format string", ...)+`:: + Library fatal logging statement, and unconditional error cause + appending. + The macros above accept the typical `printf()` conversion specifiers with the following limitations: @@ -616,59 +631,63 @@ The available format specifiers are: |`F` |Trace IR field class -|`+struct bt_field_class *+` +|`+const struct bt_field_class *+` |`f` |Trace IR field -|`+struct bt_field *+` +|`+const struct bt_field *+` |`P` |Trace IR field path -|`+struct bt_field_path *+` +|`+const struct bt_field_path *+` |`E` |Trace IR event class -|`+struct bt_event_class *+` +|`+const struct bt_event_class *+` |`e` |Trace IR event -|`+struct bt_event *+` +|`+const struct bt_event *+` |`S` |Trace IR stream class. -|`+struct bt_stream_class *+` +|`+const struct bt_stream_class *+` |`s` |Trace IR stream -|`+struct bt_stream *+` +|`+const struct bt_stream *+` |`a` |Trace IR packet -|`+struct bt_packet *+` +|`+const struct bt_packet *+` |`T` |Trace IR trace class -|`+struct bt_trace_class *+` +|`+const struct bt_trace_class *+` |`t` |Trace IR trace -|`+struct bt_trace *+` +|`+const struct bt_trace *+` |`K` |Trace IR clock class -|`+struct bt_clock_class *+` +|`+const struct bt_clock_class *+` |`k` |Trace IR clock snapshot -|`+struct bt_clock_snapshot *+` +|`+const struct bt_clock_snapshot *+` |`v` |Value object -|`+struct bt_value *+` +|`+const struct bt_value *+` + +|`R` +|Integer range set +|`const struct bt_integer_range_set *` |`n` |Message -|`+struct bt_message *+` +|`+const struct bt_message *+` |`i` |Message iterator @@ -680,31 +699,39 @@ The available format specifiers are: |`c` |Component -|`+struct bt_component *+` +|`+const struct bt_component *+` |`p` |Port -|`+struct bt_port *+` +|`+const struct bt_port *+` |`x` |Connection -|`+struct bt_connection *+` +|`+const struct bt_connection *+` |`g` |Graph -|`+struct bt_graph *+` +|`+const struct bt_graph *+` + +|`z` +|Interrupter +|`+struct bt_interrupter *+` |`l` |Plugin -|`const struct bt_plugin *` +|`+const struct bt_plugin *+` + +|`r` +|Error cause +|`+const struct bt_error_cause *+` |`o` |Object pool -|`+struct bt_object_pool *+` +|`+const struct bt_object_pool *+` |`O` |Object -|`+struct bt_object *+` +|`+const struct bt_object *+` |=== Conversion specifier examples: @@ -753,8 +780,8 @@ following macros. The component logging statement macros are named `+BT_COMP_LOG*()+` instead of `+BT_LOG*()+`: -`+BT_COMP_LOGV("format string", ...)+`:: - Component verbose logging statement. +`+BT_COMP_LOGT("format string", ...)+`:: + Component trace logging statement. `+BT_COMP_LOGD("format string", ...)+`:: Component debug logging statement. @@ -771,8 +798,8 @@ instead of `+BT_LOG*()+`: `+BT_COMP_LOGF("format string", ...)+`:: Component fatal logging statement. -`+BT_COMP_LOGV_STR("preformatted string")+`:: - Component preformatted string verbose logging statement. +`+BT_COMP_LOGT_STR("preformatted string")+`:: + Component preformatted string trace logging statement. `+BT_COMP_LOGD_STR("preformatted string")+`:: Component preformatted string debug logging statement. @@ -789,8 +816,8 @@ instead of `+BT_LOG*()+`: `+BT_COMP_LOGF_STR("preformatted string")+`:: Component preformatted string fatal logging statement. -`+BT_COMP_LOGV_ERRNO("initial message", "format string", ...)+`:: - Component `errno` string verbose logging statement. +`+BT_COMP_LOGT_ERRNO("initial message", "format string", ...)+`:: + Component `errno` string trace logging statement. `+BT_COMP_LOGD_ERRNO("initial message", "format string", ...)+`:: Component `errno` string debug logging statement. @@ -807,8 +834,8 @@ instead of `+BT_LOG*()+`: `+BT_COMP_LOGF_ERRNO("initial message", "format string", ...)+`:: Component `errno` string fatal logging statement. -`+BT_COMP_LOGV_MEM(data_ptr, data_size, "format string", ...)+`:: - Component memory verbose logging statement. +`+BT_COMP_LOGT_MEM(data_ptr, data_size, "format string", ...)+`:: + Component memory trace logging statement. `+BT_COMP_LOGD_MEM(data_ptr, data_size, "format string", ...)+`:: Component memory debug logging statement. @@ -857,10 +884,10 @@ block. The available definitions for build-time conditions are: -* `BT_LOG_ENABLED_VERBOSE` +* `BT_LOG_ENABLED_TRACE` * `BT_LOG_ENABLED_DEBUG` * `BT_LOG_ENABLED_INFO` -* `BT_LOG_ENABLED_WARN` +* `BT_LOG_ENABLED_WARNING` * `BT_LOG_ENABLED_ERROR` * `BT_LOG_ENABLED_FATAL` @@ -879,10 +906,10 @@ noticeable impact on performance. The available definitions for run-time conditions are: -* `BT_LOG_ON_VERBOSE` +* `BT_LOG_ON_TRACE` * `BT_LOG_ON_DEBUG` * `BT_LOG_ON_INFO` -* `BT_LOG_ON_WARN` +* `BT_LOG_ON_WARNING` * `BT_LOG_ON_ERROR` * `BT_LOG_ON_FATAL` @@ -991,8 +1018,8 @@ int some_function(int x) { /* ... */ -#ifdef BT_LOGV - BT_LOGV(...); +#ifdef BT_LOGT + BT_LOGT(...); #endif /* ... */ @@ -1117,11 +1144,11 @@ variable: #define BT_COMP_LOG_SELF_COMP (my_comp->self_comp) ---- -. Include `"plugins/comp-logging.h"`: +. Include `"logging/comp-logging.h"`: + [source,c] ---- -#include "plugins/comp-logging.h" +#include "logging/comp-logging.h" ---- . In the component initialization method, make sure to set the @@ -1162,7 +1189,7 @@ bt_self_component_status my_comp_init( To instrument a component class C header file (`.h`), if you have `static inline` functions in it: -. Do not include `"plugins/comp-logging.h"`! +. Do not include `"logging/comp-logging.h"`! . Require that component logging be enabled: + @@ -1170,7 +1197,7 @@ To instrument a component class C header file (`.h`), if you have ---- /* Protection: this file uses BT_COMP_LOG*() macros directly */ #ifndef BT_COMP_LOG_SUPPORTED -# error Please include "plugins/comp-logging.h" before including this file. +# error Please include "logging/comp-logging.h" before including this file. #endif ---- @@ -1249,8 +1276,11 @@ A _FATAL_-level logging statement should always be followed by * Logic error in internal code, for example an unexpected value in a `switch` statement. * Failed assertion (within `BT_ASSERT()`). -* Unsatisfied library precondition (within `BT_ASSERT_PRE()`). -|Almost none: should be executed in production. +* Unsatisfied library precondition (within `BT_ASSERT_PRE()` or + `BT_ASSERT_PRE_DEV()`). +* Unsatisfied library postcondition (within `BT_ASSERT_POST()` or + `BT_ASSERT_POST_DEV()`). +|Almost none: always enabled. |_ERROR_ | @@ -1269,23 +1299,24 @@ least exit cleanly. failure to create an empty object (no parameters): most probably failed internally because of an allocation error. * Almost any error in terminal elements: CLI and plugins. -|Almost none: should be executed in production. +|Almost none: always enabled. -|_WARN_ +|_WARNING_ | An error which still allows the execution to continue, but you judge that it should be reported to the user. -_WARN_-level logging statements are for any error or weird action that -is directly or indirectly caused by the user, often through some bad -input data. For example, not having enough memory is considered beyond -the user's control, so we always log memory errors with an _ERROR_ level -(not _FATAL_ because we usually don't abort in this condition). +_WARNING_-level logging statements are for any error or weird action +that is directly or indirectly caused by the user, often through some +bad input data. For example, not having enough memory is considered +beyond the user's control, so we always log memory errors with an +_ERROR_ level (not _FATAL_ because we usually don't abort in this +condition). | * Missing data within something that is expected to have it, but there's an alternative. * Invalid file, but recoverable/fixable. -|Almost none: can be executed in production. +|Almost none: always enabled. |_INFO_ | @@ -1305,8 +1336,7 @@ level is used for sporadic and one-shot events. * An _optional_ subsystem cannot be loaded. * An _optional_ field/datum cannot be found. | -Very little: can be executed in production if _INFO_ level information -is desired. +Very little: always enabled. |_DEBUG_ | @@ -1323,15 +1353,15 @@ an _INFO_ build. * Object copying (except fields and values). * Object freezing (whatever the type, as freezing only occurs in developer mode). -* Object cancellation. +* Object interruption. * Calling user methods and logging the result. * Setting object properties (except fields and values). | -Noticeable, but not as much as the _VERBOSE_ level: could be executed +Noticeable, but not as much as the _TRACE_ level: could be executed in production if you're going to need a thorough log for support tickets without having to rebuild the project. -|_VERBOSE_ +|_TRACE_ | Low-level debugging context information (anything that does not fit the other log levels). More appropriate for tracing in general. @@ -1345,7 +1375,7 @@ other log levels). More appropriate for tracing in general. [IMPORTANT] -- -Make sure not to use a _WARN_ (or higher) log level when the +Make sure not to use a _WARNING_ (or higher) log level when the condition leading to the logging statement can occur under normal circumstances. @@ -1353,7 +1383,7 @@ For example, a public function to get some object or property from an object by name or key that fails to find the value is not a warning scenario: the user could legitimately use this function to check if the name/key exists in the object. In this case, use the -_VERBOSE_ level (or do not log at all). +_TRACE_ level (or do not log at all). -- @@ -1434,7 +1464,7 @@ name and line number, and the <>. When Babeltrace supports terminal color codes (depends on the `BABELTRACE_TERM_COLOR` environment variable's value and what the standard output and error streams are plugged into), _INFO_-level lines -are blue, _WARN_-level lines are yellow, and _ERROR_-level and +are blue, _WARNING_-level lines are yellow, and _ERROR_-level and _FATAL_-level lines are red. Log line example: @@ -1459,8 +1489,7 @@ loads libbabeltrace2, use: ---- $ G_SLICE=always-malloc G_DEBUG=gc-friendly PYTHONMALLOC=malloc \ - BABELTRACE_NO_DLCLOSE=1 valgrind --leak-check=full \ - --suppressions=/path/to/babeltrace/extras/valgrind/popt.supp app + LIBBABELTRACE2_NO_DLCLOSE=1 valgrind --leak-check=full app ---- `G_SLICE=always-malloc` and `G_DEBUG=gc-friendly` is for GLib and @@ -1468,6 +1497,139 @@ $ G_SLICE=always-malloc G_DEBUG=gc-friendly PYTHONMALLOC=malloc \ the Python plugin provider (Valgrind will probably show a lot of errors which originate from the Python interpreter anyway). -`BABELTRACE_NO_DLCLOSE=1` makes libbabeltrace2 not close the shared +`LIBBABELTRACE2_NO_DLCLOSE=1` makes libbabeltrace2 not close the shared libraries (plugins) which it loads. You need this to see the appropriate backtrace when Valgrind shows errors. + +== Testing + +[[test-env]] +=== Environment + +`tests/utils/utils.sh` sets the environment variables for any Babeltrace +test script. + +`utils.sh` only needs to know the path to the `tests` directory within +the source and the build directories. By default, `utils.sh` assumes the +build is in tree, that is, you ran `./configure` from the source's root +directory, and sets the `BT_TESTS_SRCDIR` and `BT_TESTS_BUILDDIR` +environment variables accordingly. You can override those variables, for +example if you build out of tree. + +All test scripts eventually do something like this to source `utils.sh`, +according to where they are located relative to the `tests` directory: + +[source,bash] +---- +if [ "x${BT_TESTS_SRCDIR:-}" != "x" ]; then + UTILSSH="$BT_TESTS_SRCDIR/utils/utils.sh" +else + UTILSSH="$(dirname "$0")/../utils/utils.sh" +fi +---- + +==== Python + +You can use the `tests/utils/run_python_bt2` script to run any command +within an environment making the build's `bt2` Python package available. + +`run_python_bt2` uses <> which needs to know the +build directory, so make sure you set the `BT_TESTS_BUILDDIR` +environment variable correctly _if you build out of tree_, for example: + +---- +$ export BT_TESTS_BUILDDIR=/path/to/build/babeltrace/tests +---- + +You can run any command which needs the `bt2` Python package through +`run_python_bt2`, for example: + +---- +$ ./tests/utils/run_python_bt2 ipython3 +---- + +=== Report format + +All test scripts output the test results following the +https://testanything.org/[Test Anything Protocol] (TAP) format. + +The TAP format has two mechanisms to print additional information about +a test: + +* Print a line starting with `#` to the standard output. ++ +This is usually done with the `diag()` C function or the `diag` shell +function. + +* Print to the standard error. + + +=== Python bindings + +The `bt2` Python package tests are located in +`tests/bindings/python/bt2`. + + +==== Python test runner + +`tests/utils/python/testrunner.py` is Babeltrace's Python test runner +which loads Python files containing unit tests, finds all the test +cases, and runs the tests, producing a TAP report. + +You can see the test runner command's help with: + +---- +$ python3 ./tests/utils/python/testrunner.py --help +---- + +By default, the test runner reports failing tests (TAP's `not{nbsp}ok` +line), but continues to run other tests. You can use the `--failfast` +option to make the test runner fail as soon as a test fails. + + +==== Guides + +To run all the `bt2` Python package tests: + +* Run: ++ +---- +$ ./tests/utils/run_python_bt2 ./tests/bindings/python/bt2/test_python_bt2 +---- ++ +or: ++ +---- +$ ./tests/utils/run_python_bt2 python3 ./tests/utils/python/testrunner.py \ + ./tests/bindings/python/bt2/ -p '*.py' +---- + +To run **all the tests** in a test module (for example, +`test_value.py`): + +* Run: ++ +---- +$ ./tests/utils/run_python_bt2 python3 ./tests/utils/python/testrunner.py \ + ./tests/bindings/python/bt2 -t test_value +---- + +To run a **specific test case** (for example, `RealValueTestCase` within +`test_value.py`): + +* Run: ++ +---- +$ ./tests/utils/run_python_bt2 python3 ./tests/utils/python/testrunner.py \ + ./tests/bindings/python/bt2/ -t test_value.RealValueTestCase +---- + +To run a **specific test** (for example, +`RealValueTestCase.test_assign_pos_int` within `test_value.py`): + +* Run: ++ +---- +$ ./tests/utils/run_python_bt2 python3 ./tests/utils/python/testrunner.py \ + ./tests/bindings/python/bt2/ -t test_value.RealValueTestCase.test_assign_pos_int +----