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>
