The LTO job using gcc-7 has two issues at the moment:
- warnings about implicit fallthroughs trigger build errors:
In file included from ...common/include/rte_memory.h:22:0,
from ...linux/eal/eal_hugepage_info.c:24:
...common/include/rte_common.h: In function ‘rte_str_to_size’:
...common/include/rte_common.h:744:27: error: this statement may
fall through [-Werror=implicit-fallthrough=]
case 'G': case 'g': size *= 1024; /* fall-through */
~~~~~^~~~~~~
- if we disable this warning, linking the binaries takes too much time
and the job is terminated by Travis because it reaches the maximum
time limit
Fixes: 098cc0fea3 ("build: add option to enable LTO")
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
This patch adds an option to enable link time optimization. In addition
to LTO option itself (-flto) fat-lto-objects are being used. This is
because during the build pmdinfogen scans the generated ELF objects to
find this_pmd_name* symbol in symbol table. Without fat-lto-objects gcc
produces ELF only with extra symbols for internal use during linking.
Signed-off-by: Andrzej Ostruszka <aostruszka@marvell.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Install missing dependencies so that doc can be generated.
While at it, explicitly configure that we want the doc to be generated.
Missing dependencies are then reported as an error rather than silently
ignored.
Because of these extra dependencies, only build them in dedicated travis
jobs.
Fixes: ad2b2cfb1e ("ci: enable unit tests with Travis")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
When building under Travis (or another linux CI service), enable
running the fast-tests when the RUN_TESTS environment variable is set.
For the Travis service, introduce two new shared builds, since the
shared builds are the ones passing. Builds that are statically
linked still show some issues in some of the eal_flags tests. We make
new builds for this, rather than piggybacking, because 'at a glance'
it is difficult to determine why a build fails, and if tests were
enabled for all builds, then looking at the logs for any build would
take a significant amount of time.
Finally, the command to invoke fast tests includes a timeout
multiplier, since some CI environments don't have enough resources to
complete the tests in the default 10s timeout period.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Michael Santana <msantana@redhat.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
This helps in two ways:
1. When looking at travis page for dpdk, it's a visual distinction
2. For ccache support, the build IDs include the 'env', so we get unique
cache data.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Acked-by: Luca Boccassi <bluca@debian.org>
We try to make the planet happy travis builds dpdk.
Also, the 'sudo' flag was recently deprecated. Drop it.
Suggested-by: Luca Boccassi <bluca@debian.org>
Signed-off-by: Aaron Conole <aconole@redhat.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Acked-by: Luca Boccassi <bluca@debian.org>
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This series introduces the ability for any github mirrors of the DPDK
project, including developer mirrors, to kick off builds under the
travis CI infrastructure. For now, this just means compilation - no
other kinds of automated run exists yet. In the future, this can be
expanded to execute and report results for any test-suites that might
exist.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
The files added under .ci/ exist so that in the future, other CI
support platforms (such as cirrus, appveyor, etc.) could have a common
place to put their requisite scripts without polluting the main tree.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
