To verify that all DPDK headers are ok for inclusion directly in a C file,
and are not missing any other pre-requisite headers, we can auto-generate
for each header an empty C file that includes that header. Compiling these
files will throw errors if any header has unmet dependencies.
For some libraries, there may be some header files which are not for direct
inclusion, but rather are to be included via other header files. To allow
later checking of these files for missing includes, we separate out the
indirect include files from the direct ones.
To ensure ongoing compliance, we enable this build test as part of the
default x86 build in "test-meson-builds.sh".
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
When testing compilation and checking ABI compatibility,
there is no real need of static binaries eating disks.
The static linkage of applications was already well tested,
though the static examples tested with meson were limited to "l3fwd" only.
The static build test with make is limited to "helloworld" example.
The ABI compatibility is checked on shared libraries,
and there is no need to test again on similar builds.
A new parameter is added to the function "build",
so the ABI check is enabled only for native gcc and clang shared builds,
32-bit, generic armv8 and ppc cross compilations.
In other words, it is disabled for some static builds and some Arm ones.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
The scripts gen-abi.sh and check-abi.sh are updated
to print error messages to stderr so they are likely never ignored.
When called from test-meson-builds.sh, the standard messages on stdout
can be more quiet depending on the verbosity settings.
The beginning of the ABI check is announced in verbose mode.
The commands are printed in very verbose mode.
The check result details are available in verbose mode.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
The verbosity was meant to be set with options -v and -vv,
or possibly with the environment variables TEST_MESON_BUILD_VERBOSE
and TEST_MESON_BUILD_VERY_VERBOSE.
It is decided to keep only the options -v and -vv,
so the variables are renamed with lower case, marking them as privates.
The handling of the verbosity level is also moved upper in the script,
closer to other initializations.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Marchand <david.marchand@redhat.com>
To test the installation process of DPDK using "ninja install"
test-meson-builds.sh builds a subset of the examples using "make". To allow
more flexibility for people testing, allow the set of examples chosen for
this make test to be overridden using variable "DPDK_BUILD_TEST_EXAMPLES"
in the environment.
Since a number of example apps link against drivers directly even for
shared builds, we need to ensure that LD_LIBRARY_PATH points to the main
DPDK lib folder so any dependencies of those drivers can be found e.g. that
the PCI/vdev bus driver .so is found. [All drivers are symlinked from
drivers dir back to lib dir on install, so only one dir rather than two is
needed in the path.]
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
The x86-default environment was loaded after installing this target.
I did not see any problem with it, yet we should load corresponding
environment before installing a target.
Fixes: bd253daa7717 ("devtools: fix test of ninja install")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
The default verbosity of test-meson-builds.sh is to be quiet.
In order to better apply the verbosity policy, some file descriptors
are open to redirect to stdout or /dev/null accordingly.
The target variable and meson/ninja commands are printed in verbose modes.
The installation commands are printed only in very verbose mode.
The examples build commands are printed only in very verbose mode.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The variables DPDK_MESON_OPTIONS, PATH, PKG_CONFIG_PATH,
CPPFLAGS, CFLAGS and LDFLAGS can be customized in the config file
loaded by devtools/load-devel-config at each build.
The configuration can be adjusted per target thanks to the value set
in the DPDK_TARGET variable.
PKG_CONFIG_PATH is specific to each target, so it must be empty
before configuring each build from the file according to DPDK_TARGET.
Inheriting a default PKG_CONFIG_PATH for all targets does not make sense
and is prone to confusion.
DPDK_MESON_OPTIONS might take a global initial value from environment
to customize a build test from the shell. Example:
DPDK_MESON_OPTIONS="b_lto=true"
Some target-specific options can be added in the configuration file:
DPDK_MESON_OPTIONS="$DPDK_MESON_OPTIONS kernel_dir=$MYKERNEL"
Fixes: 272236741258 ("devtools: load target-specific compilation environment")
Cc: stable@dpdk.org
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Tested-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: David Marchand <david.marchand@redhat.com>
It's reasonably common for patches to have issues when built on 32-bits, so
to prevent this, we can add a 32-bit build (if supported) to the
"test-meson-builds.sh" script. The tricky bit is using a valid
PKG_CONFIG_LIBDIR, so for now we use two common possibilities for where that
should point to in order to get a successful build.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
When building an ABI reference with meson, some static libraries
are built and linked in apps. They are useless and take a lot of space.
Those binaries, and other useless files (examples and doc files)
in the share/ directory, are removed after being installed.
In order to save time when building the ABI reference,
the examples (which are not installed anyway) are not compiled.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
The pkg-config file was tested by building some of the examples using make,
pulling the cflags and ldflags from the pkg-config file for DPDK. However,
this only tested the shared library linkage, and not the static, so this
patch updates it to test both.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Sunil Pai G <sunil.pai.g@intel.com>
The Meson cross file is renamed from meson_mingw.txt to cross-mingw,
and is added to test-meson-builds.sh.
The only example supported on Windows so far is "helloworld",
that's why the default list of examples is overridden.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Add cross-compilation support of a PPC target in the build test matrix.
The CPU is defined as Power8, running as little endian.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
If a compiler is not found in $PATH, the compilation test is skipped.
In some cases, the compiler could be found after extending $PATH
in an environment configuration script (called by load-devel-config).
The decision to skip is deferred to a later stage, after loading the
configuration script.
In such case, the variable DPDK_TARGET, used by the configuration script
as input, is the compiler name.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Each cross-compilation case needs to define the target compiler
and the meson cross file.
Given the compiler is already defined in the cross file,
the latter is enough.
The function "build" is changed to accept a cross file alternatively
to the compiler name. In the case of a file (detected if readable),
the compiler is extracted with sed and tr, and the option --cross-file
is automatically added.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
There is no point in forcing warning-free compilation when building
an ABI reference. It is only preventing from compiling ABI reference
of old releases with recent compilers.
Note: DPDK 20.02 is built (with warnings) by GCC 10 if using -fcommon.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Static builds can take a lot of space, so reduce the number of examples
built when testing those static builds.
As makefile-based build is close to end of life, completely skip examples
in case of static linkage with make.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
Installing with ninja is quite verbose by default, hide ninja output under
TEST_MESON_BUILD_VERBOSE and TEST_MESON_BUILD_VERY_VERBOSE options.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
For normal developers, those checks are disabled.
Enabling them requires a configuration that will trigger the ABI dumps
generation as part of the existing devtools/test-build.sh and
devtools/test-meson-builds.sh scripts.
Those checks are enabled in the CI for the default meson options on x86
and aarch64 so that proposed patches are validated via our CI robot.
A cache of the ABI is stored in travis jobs to avoid rebuilding too
often.
Checks can be informational only, by setting ABI_CHECKS_WARN_ONLY when
breaking the ABI in a future release.
Explicit suppression rules have been added on internal structures
exposed to crypto drivers as the current ABI policy does not apply to
them.
This could be improved in the future by carefully splitting the headers
content with application and driver "users" in mind.
We currently have issues reported for librte_crypto recent changes for
which suppression rules have been added too.
Mellanox glue libraries are explicitly skipped as they are not part of
the application ABI.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Luca Boccassi <bluca@debian.org>
No functional change intended, prepare for reusing this code.
The config and compilation parts are separated in helpers.
Unsetting CC is moved to the caller of the helper.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Luca Boccassi <bluca@debian.org>
By default, both test-build.sh and test-meson-builds.sh scripts create the
builds they generate in the current working directory, leading to a large
number of build directories being present when testing patches. This
patchset modifies both scripts to use a DPDK_BUILD_TEST_DIR environment
variable to control where the build outputs are put.
For example, doing:
export DPDK_BUILD_TEST_DIR=__builds
./devtools/test-meson-builds.sh && ./devtools/test-build.sh \
x86_64-native-linux-clang+shared i686-native-linux-gcc
gives a "__builds" directory with 14 meson and 2 make builds (with the
meson build count depending on compiler availability)
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
Same idea than overriding PATH and PKG_CONFIG_PATH, it can be quite
useful to override compilation flags like CFLAGS, CPPFLAGS and LDFLAGS
for cross compilation or libraries that won't provide a pkg-config file.
Fixes: 272236741258 ("devtools: load target-specific compilation environment")
Signed-off-by: David Marchand <david.marchand@redhat.com>
The list of Arm configs is growing:
config/arm/arm64_armada_linux_gcc
config/arm/arm64_armv8_linux_gcc
config/arm/arm64_bluefield_linux_gcc
config/arm/arm64_dpaa_linux_gcc
config/arm/arm64_emag_linux_gcc
config/arm/arm64_n1sdp_linux_gcc
config/arm/arm64_octeontx2_linux_gcc
config/arm/arm64_thunderx2_linux_gcc
config/arm/arm64_thunderx_linux_gcc
In order to keep testing time reasonable,
and also because n1sdp is merged without a related fix in tests,
the list of configs is reduced in the script test-meson-builds.sh.
The list of tested Arm builds becomes:
build-arm64-host-clang (armv8a)
build-arm64-bluefield
build-arm64-dpaa
build-arm64-octeontx2
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
Not all versions of pkg-config in distros have support for the
--define-prefix flag [1], causing errors when building examples manually or
with test-meson-builds.sh script [2].
For the former case, we need to remove the hard-coded use of the flag in
the Makefiles.
For the latter case, the flag is necessary for builds to succeed, so we
skip the tests when it's not present, passing it as part of the pkg-config
command if it is supported.
[1]
CentOS Linux release 7.7.1908 (Core)
pkg-config version 0.27.1
[2]
## Building cmdline
Unknown option --define-prefix
gmake: Entering directory
`...ild-x86-default/install-root/usr/local/share/dpdk/examples/cmdline'
rm -f build/cmdline build/cmdline-static build/cmdline-shared
test -d build && rmdir -p build || true
Unknown option --define-prefix
Unknown option --define-prefix
gcc -O3 main.c commands.c parse_obj_list.c -o build/cmdline-shared
main.c:14:28: fatal error: cmdline_rdline.h: No such file or directory
Fixes: ca9268529d2b ("examples: support relocated DPDK install")
Fixes: 7f80a2102bbb ("devtools: test pkg-config file")
Cc: stable@dpdk.org
Reported-by: Ferruh Yigit <ferruh.yigit@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
When trying to compile some examples with libdpdk.pc,
the right environment (for default target) was not loaded.
The consequence is to not detect some dependencies because
of missing directories in PKG_CONFIG_PATH.
The environment preparation is moved to a dedicate function,
and called for the default target (cc),
before testing the install output of the default build.
Fixes: 272236741258 ("devtools: load target-specific compilation environment")
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
The meson build test fails if ccache is not available.
The use of ccache must be optional.
And if used, the compiler to check is the last word of $CC.
Fixes: e0ae780e6569 ("devtools: test compiler availability only once")
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Luca Boccassi <bluca@debian.org>
In order to re-use the same test environment as with
test-build.sh, the configuration file is loaded at each build,
after adjusting the variable DPDK_TARGET.
This is especially useful to set the variable PKG_CONFIG_PATH,
or define some meson options (without -D) in DPDK_MESON_OPTIONS.
The DPDK_TARGET values can be
aarch64-*, powerpc64-*, x86_64-*.
The matching DPDK_TARGET values for test-build.sh are
arm64-*, ppc_64-*, x86_64-*.
The advised expressions to use in the common configuration file are:
if echo $DPDK_TARGET | grep -q '^a.*64-' ; then
elif echo $DPDK_TARGET | grep -q '^p.*pc.*64' ; then
elif echo $DPDK_TARGET | grep -q '^x86_64' ; then
fi
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Luca Boccassi <bluca@debian.org>
The compilation test is skipped if the compiler is not available.
In the case of gcc/arm, it was tested both in the generic function
"build" and in the cross-compilation section.
By passing the compiler as argument of the generic function,
the test with "command" is done only once.
This small clean-up has the benefit of introducing the compiler
parameter to be used later in another improvement.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Luca Boccassi <bluca@debian.org>
With Debian and Ubuntu, the default installation path for the 64-bit
libraries is set to e.g. /usr/local/lib/x86_64-linux-gnu/, compared to
/usr/local/lib64 on Fedora and Redhat distributions. This causes issues
when using "pkg-config --define-prefix" since pkg-config assumes the prefix
to be the grandparent of where the .pc file is. On Ubuntu we then get the
cflags include path as being "/path/to/install-root/usr/local/lib/include"
i.e. with an extra "lib" in the path.
This issue only applies for test installs on Ubuntu and similar distros,
and is not a problem for regular installs since the --define-prefix
parameter would not be passed to pkg-config in those cases.
The workaround for this in our test build script is to explicitly make
"lib" the "libdir" setting for the install, overriding the distro-provided
default.
Fixes: 7f80a2102bbb ("devtools: test pkg-config file")
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
The pkg-config file generated as part of the build of DPDK should allow
applications to be built with an installed DPDK. We can test this as
part of the build by doing an install of DPDK to a temporary directory
within the build folder, and by then compiling up a few sample apps
using make working off that directory.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Allow the script to run with a reduced set of builds if clang, or
other compilers, are missing.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
The pipefail option is not supported in /bin/sh, just in bash/ksh and
similar shells - which means it's there by default on most Linux distros
but not on e.g. FreeBSD. Therefore we check for it's presence before
setting the option, and if it's missing, we upgrade verbosity level if
needed to ensure we never hide any build failures.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
The use of "==" is non-standard extension from bash, so use "="
for comparisons instead.
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Older versions of GCC, such as on Redhat/CentOS 7, don't support
-march=nehalem, but need -march=corei7 instead.
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
If either gcc or clang are missing, skip doing those builds.
This allows a setup to only do, e.g. gcc tests.
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
The test-meson-builds.sh script correctly detects the source directory and
builds the native builds successfully in a directory outside of the source
tree. However, the paths to the cross-files are not prefixed with the
source directory path, so the cross-builds all fail. Fix this by prepending
the source directory path appropriately.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
When piping the ninja command through cat, we lose the error value from
the call to ninja in the case of failure. This prevents the script from
exiting at the first broken build. Fix this by setting the "pipefail"
shell option.
Fixes: 4bcb9b768604 ("devtools: add verbose option to meson build test")
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Rename the cross files for meson compilation from having linuxapp
in the name to just linux in the name.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
When running ninja, the commands are, by default, always printed on top of
each other. For those who want more detail in the output, two levels of
verbose output has been added to the test-meson-builds script. When "-v" is
passed, or the "TEST_MESON_BUILD_VERBOSE" flag is set in the environment,
then the output of ninja is passed through "cat" to prevent each line
overwriting the next. If "-vv" is passed, or
"TEST_MESON_BUILD_VERY_VERBOSE" is set in the environment, then ninja is
called with the "-v" flag to print out each command in full as it is
executing.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
readlink option "-m" is not supported on FreeBSD (checked on BSD 11),
so change to the largely-equivalent "-f" flag.
Fixes: a55277a788df ("devtools: add test script for meson builds")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
The current check to see whether we need to call meson or just ninja
simply checked if the build directory existed. However, if meson was run
but failed, the build directory would still exist. We can fix this by
instead checking for the build.ninja file inside the directory. Once that
is present, we can use ninja safely and let it worry about rerunning
meson if necessary.
Fixes: a55277a788df ("devtools: add test script for meson builds")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
For usability, the default build type in meson is static, so that
binaries can be run from the build directory easily. However, static
builds take more space, so for build-testing purposes default to using
shared builds where possible.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
The default test script covers only default host cc compiler, either gcc or
clang, the fix is to increase the coverage by adding one more to cover
clang and the others for gcc.
Fixes: a55277a788 ("devtools: add test script for meson builds")
Cc: stable@dpdk.org
Signed-off-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Song Zhu <song.zhu@arm.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
On some linux distributions, eg: CentOS, the ninja executable has a
different name: ninja-build, this patch is to check and adapt to it
accordingly.
./devtools/test-meson-builds.sh: line 24: ninja: command not found
Fixes: a55277a788 ("devtools: add test script for meson builds")
Cc: stable@dpdk.org
Signed-off-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Song Zhu <song.zhu@arm.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
For cross-builds the CC environmental variable only applies for compiling
native binaries i.e. pmdinfogen, so setting it to a cross-build compiler
will only cause problems. Leave the value unset in the script to use the
platform-default compiler.
Fixes: a55277a788df ("devtools: add test script for meson builds")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
To simplify testing with the meson and ninja builds, we can add a script
to set up and do multiple builds. Currently this script sets up:
* clang and gcc builds
* builds using static and shared linkage for binaries (libs are always
built as both)
* a build using the lowest instruction-set level for x86 (-march=nehalem)
* cross-builds for each cross-file listed in config/arm
Each build is configured in a directory ending in *-build, and then for
the build stage, we just call ninja in each directory in turn. [i.e. we
assume every directory starting with "build-" is a meson build, which is
probably an ok assumption].
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
