1 .. SPDX-License-Identifier: BSD-3-Clause
2 Copyright 2018 The DPDK contributors
12 This document specifies the preferred style for source files in the DPDK source tree.
13 It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2 Kernel Developer's Manual (see man style(9)), but was heavily modified for the needs of the DPDK.
18 The rules and guidelines given in this document cannot cover every situation, so the following general guidelines should be used as a fallback:
20 * The code style should be consistent within each individual file.
21 * In the case of creating new files, the style should be consistent within each file in a given directory or module.
22 * The primary reason for coding standards is to increase code readability and comprehensibility, therefore always use whatever option will make the code easiest to read.
24 Line length is recommended to be not more than 80 characters, including comments.
25 [Tab stop size should be assumed to be 8-characters wide].
29 The above is recommendation, and not a hard limit.
30 However, it is expected that the recommendations should be followed in all but the rarest situations.
38 These comments should be used in normal cases.
39 To document a public API, a doxygen-like format must be used: refer to :ref:`doxygen_guidelines`.
44 * VERY important single-line comments look like this.
47 /* Most single-line comments look like this. */
50 * Multi-line comments look like this. Make them real sentences. Fill
51 * them so they look like real paragraphs.
57 Each file must begin with a special comment containing the
58 `Software Package Data Exchange (SPDX) License Identfier <https://spdx.org/using-spdx-license-identifier>`_.
60 Generally this is the BSD License, except for code granted special exceptions.
61 The SPDX licences identifier is sufficient, a file should not contain
62 an additional text version of the license (boilerplate).
64 After any copyright header, a blank line should be left before any other contents, e.g. include statements in a C file.
66 C Preprocessor Directives
67 -------------------------
72 In DPDK sources, the include files should be ordered as following:
74 #. libc includes (system includes first)
76 #. DPDK misc libraries includes
77 #. application-specific includes
79 Include files from the local application directory are included using quotes, while includes from other paths are included using angle brackets: "<>".
91 #include <rte_mempool.h>
93 #include "application.h"
98 Headers should be protected against multiple inclusion with the usual:
107 #endif /* _FILE_H_ */
113 Do not ``#define`` or declare names except with the standard DPDK prefix: ``RTE_``.
114 This is to ensure there are no collisions with definitions in the application itself.
116 The names of "unsafe" macros (ones that have side effects), and the names of macros for manifest constants, are all in uppercase.
118 The expansions of expression-like macros are either a single token or have outer parentheses.
119 If a macro is an inline expansion of a function, the function name is all in lowercase and the macro has the same name all in uppercase.
120 If the macro encapsulates a compound statement, enclose it in a do-while loop, so that it can be used safely in if statements.
121 Any final statement-terminating semicolon should be supplied by the macro invocation rather than the macro, to make parsing easier for pretty-printers and editors.
127 #define MACRO(x, y) do { \
128 variable = (x) + (y); \
134 Wherever possible, enums and inline functions should be preferred to macros, since they provide additional degrees of type-safety and can allow compilers to emit extra warnings about unsafe code.
136 Conditional Compilation
137 ~~~~~~~~~~~~~~~~~~~~~~~
139 * When code is conditionally compiled using ``#ifdef`` or ``#if``, a comment may be added following the matching
140 ``#endif`` or ``#else`` to permit the reader to easily discern where conditionally compiled code regions end.
141 * This comment should be used only for (subjectively) long regions, regions greater than 20 lines, or where a series of nested ``#ifdef``'s may be confusing to the reader.
142 Exceptions may be made for cases where code is conditionally not compiled for the purposes of lint(1), or other tools, even though the uncompiled region may be small.
143 * The comment should be separated from the ``#endif`` or ``#else`` by a single space.
144 * For short conditionally compiled regions, a closing comment should not be used.
145 * The comment for ``#endif`` should match the expression used in the corresponding ``#if`` or ``#ifdef``.
146 * The comment for ``#else`` and ``#elif`` should match the inverse of the expression(s) used in the preceding ``#if`` and/or ``#elif`` statements.
147 * In the comments, the subexpression ``defined(FOO)`` is abbreviated as "FOO".
148 For the purposes of comments, ``#ifndef FOO`` is treated as ``#if !defined(FOO)``.
153 #include <sys/ktrace.h>
157 /* A large region here, or other conditional code. */
158 #else /* !COMPAT_43 */
160 #endif /* COMPAT_43 */
163 /* Yet another large region here, or other conditional code. */
164 #else /* COMPAT_43 */
166 #endif /* !COMPAT_43 */
170 Conditional compilation should be used only when absolutely necessary, as it increases the number of target binaries that need to be built and tested.
178 For fixed/minimum-size integer values, the project uses the form uintXX_t (from stdint.h) instead of older BSD-style integer identifiers of the form u_intXX_t.
183 * Enumeration values are all uppercase.
187 enum enumtype { ONE, TWO } et;
189 * Enum types should be used in preference to macros #defining a set of (sequential) values.
190 * Enum types should be prefixed with ``rte_`` and the elements by a suitable prefix [generally starting ``RTE_<enum>_`` - where <enum> is a shortname for the enum type] to avoid namespace collisions.
195 The developer should group bitfields that are included in the same integer, as follows:
212 Variable Declarations
213 ~~~~~~~~~~~~~~~~~~~~~
215 In declarations, do not put any whitespace between asterisks and adjacent tokens, except for tokens that are identifiers related to types.
216 (These identifiers are the names of basic types, type qualifiers, and typedef-names other than the one being declared.)
217 Separate these identifiers from asterisks using a single space.
223 int *x; /* no space after asterisk */
224 int * const x; /* space after asterisk when using a type qualifier */
226 * All externally-visible variables should have an ``rte_`` prefix in the name to avoid namespace collisions.
227 * Do not use uppercase letters - either in the form of ALL_UPPERCASE, or CamelCase - in variable names.
228 Lower-case letters and underscores only.
230 Structure Declarations
231 ~~~~~~~~~~~~~~~~~~~~~~
233 * In general, when declaring variables in new structures, declare them sorted by use, then by size (largest to smallest), and then in alphabetical order.
234 Sorting by use means that commonly used variables are used together and that the structure layout makes logical sense.
235 Ordering by size then ensures that as little padding is added to the structure as possible.
236 * For existing structures, additions to structures should be added to the end so for backward compatibility reasons.
237 * Each structure element gets its own line.
238 * Try to make the structure readable by aligning the member names using spaces as shown below.
239 * Names following extremely long types, which therefore cannot be easily aligned with the rest, should be separated by a single space.
244 struct foo *next; /* List of active foo. */
245 struct mumble amumble; /* Comment for mumble. */
246 int bar; /* Try to align the comments. */
247 struct verylongtypename *baz; /* Won't fit with other members */
251 * Major structures should be declared at the top of the file in which they are used, or in separate header files if they are used in multiple source files.
252 * Use of the structures should be by separate variable declarations and those declarations must be extern if they are declared in a header file.
253 * Externally visible structure definitions should have the structure name prefixed by ``rte_`` to avoid namespace collisions.
257 Uses of ``bool`` in structures are not preferred as is wastes space and
258 it's also not clear as to what type size the bool is. A preferred use of
259 ``bool`` is mainly as a return type from functions that return true/false,
260 and maybe local variable functions.
262 Ref: `LKML <https://lkml.org/lkml/2017/11/21/384>`_
267 Use queue(3) macros rather than rolling your own lists, whenever possible.
268 Thus, the previous example would be better written:
272 #include <sys/queue.h>
275 LIST_ENTRY(foo) link; /* Use queue macros for foo lists. */
276 struct mumble amumble; /* Comment for mumble. */
277 int bar; /* Try to align the comments. */
278 struct verylongtypename *baz; /* Won't fit with other members */
280 LIST_HEAD(, foo) foohead; /* Head of global foo list. */
283 DPDK also provides an optimized way to store elements in lockless rings.
284 This should be used in all data-path code, when there are several consumer and/or producers to avoid locking for concurrent access.
289 Avoid using typedefs for structure types.
295 struct my_struct_type {
299 struct my_struct_type my_var;
306 typedef struct my_struct_type {
310 my_struct_type my_var
313 Typedefs are problematic because they do not properly hide their underlying type;
314 for example, you need to know if the typedef is the structure itself, as shown above, or a pointer to the structure.
315 In addition, they must be declared exactly once, whereas an incomplete structure type can be mentioned as many times as necessary.
316 Typedefs are difficult to use in stand-alone header files.
317 The header that defines the typedef must be included before the header that uses it, or by the header that uses it (which causes namespace pollution),
318 or there must be a back-door mechanism for obtaining the typedef.
320 Note that #defines used instead of typedefs also are problematic (since they do not propagate the pointer type correctly due to direct text replacement).
321 For example, ``#define pint int *`` does not work as expected, while ``typedef int *pint`` does work.
322 As stated when discussing macros, typedefs should be preferred to macros in cases like this.
324 When convention requires a typedef; make its name match the struct tag.
325 Avoid typedefs ending in ``_t``, except as specified in Standard C or by POSIX.
329 It is recommended to use typedefs to define function pointer types, for reasons of code readability.
330 This is especially true when the function type is used as a parameter to another function.
337 * Definition of a remote launch function.
339 typedef int (lcore_function_t)(void *);
341 /* launch a function of lcore_function_t type */
342 int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned slave_id);
351 * Indentation is a hard tab, that is, a tab character, not a sequence of spaces,
355 Global whitespace rule in DPDK, use tabs for indentation, spaces for alignment.
357 * Do not put any spaces before a tab for indentation.
358 * If you have to wrap a long statement, put the operator at the end of the line, and indent again.
359 * For control statements (if, while, etc.), continuation it is recommended that the next line be indented by two tabs, rather than one,
360 to prevent confusion as to whether the second line of the control statement forms part of the statement body or not.
361 Alternatively, the line continuation may use additional spaces to line up to an appropriately point on the preceding line, for example, to align to an opening brace.
365 As with all style guidelines, code should match style already in use in an existing file.
369 while (really_long_variable_name_1 == really_long_variable_name_2 &&
370 var3 == var4){ /* confusing to read as */
371 x = y + z; /* control stmt body lines up with second line of */
372 a = b + c; /* control statement itself if single indent used */
375 if (really_long_variable_name_1 == really_long_variable_name_2 &&
376 var3 == var4){ /* two tabs used */
377 x = y + z; /* statement body no longer lines up */
381 z = a + really + long + statement + that + needs +
382 two + lines + gets + indented + on + the +
383 second + and + subsequent + lines;
386 * Do not add whitespace at the end of a line.
388 * Do not add whitespace or a blank line at the end of a file.
391 Control Statements and Loops
392 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
394 * Include a space after keywords (if, while, for, return, switch).
395 * Do not use braces (``{`` and ``}``) for control statements with zero or just a single statement, unless that statement is more than a single line in which case the braces are permitted.
399 for (p = buf; *p != '\0'; ++p)
404 z = a + really + long + statement + that + needs +
405 two + lines + gets + indented + on + the +
406 second + and + subsequent + lines;
413 val = realloc(val, newsize);
416 * Parts of a for loop may be left empty.
420 for (; cnt < 15; cnt++) {
425 * Closing and opening braces go on the same line as the else keyword.
426 * Braces that are not necessary should be left out.
442 * Do not use spaces after function names.
443 * Commas should have a space after them.
444 * No spaces after ``(`` or ``[`` or preceding the ``]`` or ``)`` characters.
448 error = function(a1, a2);
456 * Unary operators do not require spaces, binary operators do.
457 * Do not use parentheses unless they are required for precedence or unless the statement is confusing without them.
458 However, remember that other people may be more easily confused than you.
463 Exits should be 0 on success, or 1 on failure.
468 * Avoid obvious comments such as
469 * "Exit 0 on success."
476 * Variables should be declared at the start of a block of code rather than in the middle.
477 The exception to this is when the variable is ``const`` in which case the declaration must be at the point of first use/assignment.
478 * When declaring variables in functions, multiple variables per line are OK.
479 However, if multiple declarations would cause the line to exceed a reasonable line length, begin a new set of declarations on the next line rather than using a line continuation.
480 * Be careful to not obfuscate the code by initializing variables in the declarations, only the last variable on a line should be initialized.
481 If multiple variables are to be initialized when defined, put one per line.
482 * Do not use function calls in initializers, except for ``const`` variables.
486 int i = 0, j = 0, k = 0; /* bad, too many initializer */
488 char a = 0; /* OK, one variable per line with initializer */
491 float x, y = 0.0; /* OK, only last variable has initializer */
497 * Casts and sizeof statements are not followed by a space.
498 * Always write sizeof statements with parenthesis.
499 The redundant parenthesis rules do not apply to sizeof(var) instances.
501 C Function Definition, Declaration and Use
502 -------------------------------------------
507 * It is recommended (and generally required by the compiler) that all non-static functions are prototyped somewhere.
508 * Functions local to one source module should be declared static, and should not be prototyped unless absolutely necessary.
509 * Functions used from other parts of code (external API) must be prototyped in the relevant include file.
510 * Function prototypes should be listed in a logical order, preferably alphabetical unless there is a compelling reason to use a different ordering.
511 * Functions that are used locally in more than one module go into a separate header file, for example, "extern.h".
512 * Do not use the ``__P`` macro.
513 * Functions that are part of an external API should be documented using Doxygen-like comments above declarations. See :ref:`doxygen_guidelines` for details.
514 * Functions that are part of the external API must have an ``rte_`` prefix on the function name.
515 * Do not use uppercase letters - either in the form of ALL_UPPERCASE, or CamelCase - in function names. Lower-case letters and underscores only.
516 * When prototyping functions, associate names with parameter types, for example:
520 void function1(int fd); /* good */
521 void function2(int); /* bad */
523 * Short function prototypes should be contained on a single line.
524 Longer prototypes, e.g. those with many parameters, can be split across multiple lines.
525 The second and subsequent lines should be further indented as for line statement continuations as described in the previous section.
529 static char *function1(int _arg, const char *_arg2,
533 static void usage(void);
537 Unlike function definitions, the function prototypes do not need to place the function return type on a separate line.
542 * The function type should be on a line by itself preceding the function.
543 * The opening brace of the function body should be on a line by itself.
548 function(int a1, int a2, float fl, int a4)
552 * Do not declare functions inside other functions.
553 ANSI C states that such declarations have file scope regardless of the nesting of the declaration.
554 Hiding file declarations in what appears to be a local scope is undesirable and will elicit complaints from a good compiler.
555 * Old-style (K&R) function declaration should not be used, use ANSI function declarations instead as shown below.
556 * Long argument lists should be wrapped as described above in the function prototypes section.
561 * All major routines should have a comment briefly describing what
562 * they do. The comment before the "main" routine should describe
563 * what the program does.
566 main(int argc, char *argv[])
572 C Statement Style and Conventions
573 ---------------------------------
578 * NULL is the preferred null pointer constant.
579 Use NULL instead of ``(type *)0`` or ``(type *)NULL``, except where the compiler does not know the destination type e.g. for variadic args to a function.
580 * Test pointers against NULL, for example, use:
584 if (p == NULL) /* Good, compare pointer to NULL */
586 if (!p) /* Bad, using ! on pointer */
589 * Do not use ! for tests unless it is a boolean, for example, use:
593 if (*p == '\0') /* check character against (char)0 */
598 * Functions which create objects, or allocate memory, should return pointer types, and NULL on error.
599 The error type should be indicated may setting the variable ``rte_errno`` appropriately.
600 * Functions which work on bursts of packets, such as RX-like or TX-like functions, should return the number of packets handled.
601 * Other functions returning int should generally behave like system calls:
602 returning 0 on success and -1 on error, setting ``rte_errno`` to indicate the specific type of error.
603 * Where already standard in a given library, the alternative error approach may be used where the negative value is not -1 but is instead ``-errno`` if relevant, for example, ``-EINVAL``.
604 Note, however, to allow consistency across functions returning integer or pointer types, the previous approach is preferred for any new libraries.
605 * For functions where no error is possible, the function type should be ``void`` not ``int``.
606 * Routines returning ``void *`` should not have their return values cast to any pointer type.
607 (Typecasting can prevent the compiler from warning about missing prototypes as any implicit definition of a function returns int,
608 which, unlike ``void *``, needs a typecast to assign to a pointer variable.)
612 The above rule about not typecasting ``void *`` applies to malloc, as well as to DPDK functions.
614 * Values in return statements should not be enclosed in parentheses.
619 In the DPDK environment, use the logging interface provided:
623 /* register log types for this application */
624 int my_logtype1 = rte_log_register("myapp.log1");
625 int my_logtype2 = rte_log_register("myapp.log2");
627 /* set global log level to INFO */
628 rte_log_set_global_level(RTE_LOG_INFO);
630 /* only display messages higher than NOTICE for log2 (default
632 rte_log_set_level(my_logtype2, RTE_LOG_NOTICE);
634 /* enable all PMD logs (whose identifier string starts with "pmd.") */
635 rte_log_set_level_pattern("pmd.*", RTE_LOG_DEBUG);
637 /* log in debug level */
638 rte_log_set_global_level(RTE_LOG_DEBUG);
639 RTE_LOG(DEBUG, my_logtype1, "this is a debug level message\n");
640 RTE_LOG(INFO, my_logtype1, "this is a info level message\n");
641 RTE_LOG(WARNING, my_logtype1, "this is a warning level message\n");
642 RTE_LOG(WARNING, my_logtype2, "this is a debug level message (not displayed)\n");
644 /* log in info level */
645 rte_log_set_global_level(RTE_LOG_INFO);
646 RTE_LOG(DEBUG, my_logtype1, "debug level message (not displayed)\n");
651 * When a test is done in a critical zone (called often or in a data path) the code can use the ``likely()`` and ``unlikely()`` macros to indicate the expected, or preferred fast path.
652 They are expanded as a compiler builtin and allow the developer to indicate if the branch is likely to be taken or not. Example:
656 #include <rte_branch_prediction.h>
662 The use of ``likely()`` and ``unlikely()`` should only be done in performance critical paths,
663 and only when there is a clearly preferred path, or a measured performance increase gained from doing so.
664 These macros should be avoided in non-performance-critical code.
666 Static Variables and Functions
667 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
669 * All functions and variables that are local to a file must be declared as ``static`` because it can often help the compiler to do some optimizations (such as, inlining the code).
670 * Functions that should be inlined should to be declared as ``static inline`` and can be defined in a .c or a .h file.
673 Static functions defined in a header file must be declared as ``static inline`` in order to prevent compiler warnings about the function being unused.
678 The ``const`` attribute should be used as often as possible when a variable is read-only.
683 The ``asm`` and ``volatile`` keywords do not have underscores. The AT&T syntax should be used.
684 Input and output operands should be named to avoid confusion, as shown in the following example:
688 asm volatile("outb %[val], %[port]"
696 * Forever loops are done with for statements, not while statements.
697 * Elements in a switch statement that cascade should have a FALLTHROUGH comment. For example:
701 switch (ch) { /* Indent the switch. */
702 case 'a': /* Don't indent the case. */
703 aflag = 1; /* Indent case body one tab. */
717 DPDK provides infrastructure to perform logging during runtime. This is very
718 useful for enabling debug output without recompilation. To enable or disable
719 logging of a particular topic, the ``--log-level`` parameter can be provided
720 to EAL, which will change the log level. DPDK code can register topics,
721 which allows the user to adjust the log verbosity for that specific topic.
723 In general, the naming scheme is as follows: ``type.section.name``
725 * Type is the type of component, where ``lib``, ``pmd``, ``bus`` and ``user``
726 are the common options.
727 * Section refers to a specific area, for example a poll-mode-driver for an
728 ethernet device would use ``pmd.net``, while an eventdev PMD uses
730 * The name identifies the individual item that the log applies to.
731 The name section must align with
732 the directory that the PMD code resides. See examples below for clarity.
736 * The virtio network PMD in ``drivers/net/virtio`` uses ``pmd.net.virtio``
737 * The eventdev software poll mode driver in ``drivers/event/sw`` uses ``pmd.event.sw``
738 * The octeontx mempool driver in ``drivers/mempool/octeontx`` uses ``pmd.mempool.octeontx``
739 * The DPDK hash library in ``lib/librte_hash`` uses ``lib.hash``
744 In addition to the above logging topic, any PMD or library can further split
745 logging output by using "specializations". A specialization could be the
746 difference between initialization code, and logs of events that occur at runtime.
748 An example could be the initialization log messages getting one
749 specialization, while another specialization handles mailbox command logging.
750 Each PMD, library or component can create as many specializations as required.
752 A specialization looks like this:
754 * Initialization output: ``type.section.name.init``
755 * PF/VF mailbox output: ``type.section.name.mbox``
757 A real world example is the i40e poll mode driver which exposes two
758 specializations, one for initialization ``pmd.net.i40e.init`` and the other for
759 the remaining driver logs ``pmd.net.i40e.driver``.
761 Note that specializations have no formatting rules, but please follow
762 a precedent if one exists. In order to see all current log topics and
763 specializations, run the ``app/test`` binary, and use the ``dump_log_types``
768 All Python code should work with Python 2.7+ and 3.2+ and be compliant with
769 `PEP8 (Style Guide for Python Code) <https://www.python.org/dev/peps/pep-0008/>`_.
771 The ``pep8`` tool can be used for testing compliance with the guidelines.
773 Integrating with the Build System
774 ---------------------------------
776 DPDK is built using the tools ``meson`` and ``ninja``.
778 Therefore all new component additions should include a ``meson.build`` file,
779 and should be added to the component lists in the ``meson.build`` files in the
780 relevant top-level directory:
781 either ``lib`` directory or a ``driver`` subdirectory.
783 Meson Build File Contents - Libraries
784 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
786 The ``meson.build`` file for a new DPDK library should be of the following basic
789 .. code-block:: python
791 sources = files('file1.c', ...)
792 headers = files('file1.h', ...)
795 This will build based on a number of conventions and assumptions within the DPDK
796 itself, for example, that the library name is the same as the directory name in
797 which the files are stored.
799 For a library ``meson.build`` file, there are number of variables which can be
800 set, some mandatory, others optional. The mandatory fields are:
803 **Default Value = []**.
804 This variable should list out the files to be compiled up to create the
805 library. Files must be specified using the meson ``files()`` function.
808 The optional fields are:
811 **Default Value = true**
812 Used to optionally compile a library, based on its dependencies or
813 environment. When set to "false" the ``reason`` value, explained below, should
814 also be set to explain to the user why the component is not being built.
815 A simple example of use would be:
817 .. code-block:: python
821 reason = 'only supported on Linux'
826 **Default Value = [<-march/-mcpu flags>]**.
827 Used to specify any additional cflags that need to be passed to compile
828 the sources in the library.
831 **Default Value = ['eal']**.
832 Used to list the internal library dependencies of the library. It should
833 be assigned to using ``+=`` rather than overwriting using ``=``. The
834 dependencies should be specified as strings, each one giving the name of
835 a DPDK library, without the ``librte_`` prefix. Dependencies are handled
836 recursively, so specifying e.g. ``mempool``, will automatically also
837 make the library depend upon the mempool library's dependencies too -
838 ``ring`` and ``eal``. For libraries that only depend upon EAL, this
839 variable may be omitted from the ``meson.build`` file. For example:
841 .. code-block:: python
847 **Default Value = []**.
848 Used to specify external dependencies of this library. They should be
849 returned as dependency objects, as returned from the meson
850 ``dependency()`` or ``find_library()`` functions. Before returning
851 these, they should be checked to ensure the dependencies have been
852 found, and, if not, the ``build`` variable should be set to ``false``.
855 .. code-block:: python
857 my_dep = dependency('libX', required: 'false')
866 **Default Value = []**.
867 Used to return the list of header files for the library that should be
868 installed to $PREFIX/include when ``ninja install`` is run. As with
869 source files, these should be specified using the meson ``files()``
873 **Default Value = []**.
874 Used to indicate any additional header file paths which should be
875 added to the header search path for other libs depending on this
876 library. EAL uses this so that other libraries building against it
877 can find the headers in subdirectories of the main EAL directory. The
878 base directory of each library is always given in the include path,
879 it does not need to be specified here.
882 **Default Value = library name derived from the directory name**.
883 If a library's .so or .a file differs from that given in the directory
884 name, the name should be specified using this variable. In practice,
885 since the convention is that for a library called ``librte_xyz.so``, the
886 sources are stored in a directory ``lib/librte_xyz``, this value should
887 never be needed for new libraries.
891 The name value also provides the name used to find the function version
892 map file, as part of the build process, so if the directory name and
893 library names differ, the ``version.map`` file should be named
894 consistently with the library, not the directory
897 **Default Value = []**.
898 This variable can be used to pass to the library build some pre-built
899 objects that were compiled up as part of another target given in the
900 included library ``meson.build`` file.
903 **Default Value = '<unknown reason>'**.
904 This variable should be used when a library is not to be built i.e. when
905 ``build`` is set to "false", to specify the reason why a library will not be
906 built. For missing dependencies this should be of the form
907 ``'missing dependency, "libname"'``.
909 use_function_versioning
910 **Default Value = false**.
911 Specifies if the library in question has ABI versioned functions. If it
912 has, this value should be set to ensure that the C files are compiled
913 twice with suitable parameters for each of shared or static library
916 Meson Build File Contents - Drivers
917 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
919 For drivers, the values are largely the same as for libraries. The variables
935 **Default Value = <driver directory>** Some drivers include a base
936 directory for additional source files and headers, so we have this
937 variable to allow the headers from that base directory to be found when
938 compiling driver sources. Should be appended to using ``+=`` rather than
939 overwritten using ``=``. The values appended should be meson include
940 objects got using the ``include_directories()`` function. For example:
942 .. code-block:: python
944 includes += include_directories('base')
947 As above, though note that each driver class can define it's own naming
948 scheme for the resulting ``.so`` files.
951 As above, generally used for the contents of the ``base`` directory.
954 **Default Value = []**
955 This variable is used to pass additional library link flags through to
956 the DPDK pkgconfig file generated, for example, to track any additional
957 libraries that may need to be linked into the build - especially when
958 using static libraries. Anything added here will be appended to the end
959 of the ``pkgconfig --libs`` output.