From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id E16AB5A44 for ; Thu, 24 Jan 2019 19:31:51 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2019 10:31:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,517,1539673200"; d="scan'208";a="137486016" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.54]) by fmsmga002.fm.intel.com with SMTP; 24 Jan 2019 10:31:47 -0800 Received: by (sSMTP sendmail emulation); Thu, 24 Jan 2019 18:31:44 +0000 Date: Thu, 24 Jan 2019 18:31:43 +0000 From: Bruce Richardson To: Aaron Conole Cc: Michael Santana , dev@dpdk.org, Thomas Monjalon , Ferruh Yigit Message-ID: <20190124183143.GA297252@bricha3-MOBL.ger.corp.intel.com> References: <20190123220714.20763-1-msantana@redhat.com> <20190124093547.GA155072@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) Subject: Re: [dpdk-dev] [PATCH] Introduce travis builds for github repositories X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 18:31:52 -0000 On Thu, Jan 24, 2019 at 01:11:36PM -0500, Aaron Conole wrote: > Bruce Richardson writes: > > > On Wed, Jan 23, 2019 at 05:07:14PM -0500, Michael Santana wrote: > >> 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 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. > >> > >> Additionally, the travis service will send an email to the test-report > >> list informing anyone interested in the automated build (including a > >> result). > >> > >> Signed-off-by: Aaron Conole > >> Signed-off-by: Michael Santana > >> --- > >> .ci/linux-build.sh | 34 +++++++++++++++++++++++++ > >> .ci/linux-setup.sh | 3 +++ > >> .travis.yml | 39 +++++++++++++++++++++++++++++ > >> MAINTAINERS | 6 +++++ > >> doc/guides/contributing/patches.rst | 3 +++ > >> 5 files changed, 85 insertions(+) > >> create mode 100755 .ci/linux-build.sh > >> create mode 100755 .ci/linux-setup.sh > >> create mode 100644 .travis.yml > >> > >> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh > >> new file mode 100755 > >> index 0000000000..2cfaa05058 > >> --- /dev/null > >> +++ b/.ci/linux-build.sh > >> @@ -0,0 +1,34 @@ > >> +#!/bin/bash > >> + > >> +# check for whether we're clang or gcc > >> +# setup the right options depending on the environment variables > >> +# run the build > >> + > >> +# Just used for the 'classic' configuration system (ie: make) > >> +set_conf() { > >> + c="$1/.config" > >> + shift > >> + > >> + if grep -q "$1" "$c"; then > >> + sed -i "s:^$1=.*$:$1=$2:g" $c > >> + else > >> + echo $1=$2 >> "$c" > >> + fi > >> +} > >> + > >> + > >> +if [ "${NINJABUILD}" == "1" ]; then > >> + meson build > >> + ninja -C build > > > > Would calling test-meson-builds.sh be a good option here? It runs multiple > > builds rather than a single one. > > Maybe it would be better to just fold in the options? For example, we > already have support for SHARED vs STATIC builds using the standard > config. Then all we do is change to look like: > > DEF_LIB="static" > if [ "${SHARED}" == "1" ]; then > DEF_LIB="shared" > fi > > meson build --werror -Dexamples=all --default-library=${DEF_LIB} > > That will build the static vs shared. I like it because it keeps the > 'matrix' build from travis (see for example, > https://travis-ci.org/orgcandman/dpdk). Then if some build fails we can > dive into which one failed a little bit easier. Plus, > test-meson-builds.sh requires all the various compilers be installed to > work right. I'd rather just flesh out the ci build. That's fine doing it that way. I don't mind what way we get the coverage. I imagine we can easily expand the coverage to check default vs native builds, and 64-bit vs 32-bit builds later. > > >> +else > >> + make config T=x86_64-native-linuxapp-${CC} > >> + if [ "${SHARED}" == "1" ]; then > >> + set_conf build CONFIG_RTE_BUILD_SHARED_LIB y > >> + fi > >> + > >> + if [ "${KERNEL}" == "1" ]; then > >> + echo Unsupported kernel builds at the moment > >> + fi There is the --Denable_kmods parameter to meson which is equivalent to this, if you want to include it in the meson parameters. > >> + > >> + make all > >> +fi > >> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh > >> new file mode 100755 > >> index 0000000000..6f9849cb94 > >> --- /dev/null > >> +++ b/.ci/linux-setup.sh > >> @@ -0,0 +1,3 @@ > >> +#!/bin/sh > >> + > >> +python3.5 -m pip install --upgrade meson --user > >> diff --git a/.travis.yml b/.travis.yml > >> new file mode 100644 > >> index 0000000000..432d6c9c6c > >> --- /dev/null > >> +++ b/.travis.yml > >> @@ -0,0 +1,39 @@ > >> +language: c > >> +compiler: > >> + - gcc > >> + - clang > >> + > >> +os: > >> + - linux > >> + > >> +addons: > >> + apt: > >> + sources: > >> + - deadsnakes #source for python 3.5 > >> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2' > >> + packages: > >> + - libnuma-dev > >> + - linux-headers-$(uname -r) > >> + - python3.5 > >> + - python3-pip > >> + - ninja-build > >> + > > > > Other optional packages we should consider including: libbsd, pcap, > > libcrypto, jansson, zlib. > > Makes sense. > > > Ideally, I suppose we'd have two setups - one with all the packages, the > > other only with the minimum. > > One thing I'd really like to incorporate is a bunch of unit tests that I > can launch... > > > Thanks for the review, Bruce! Yes, unit test cleanup is something I'd like to see too. The work done to split the unit tests into suites that can be run using meson is a start, but we need to start ensuring reliable test passing suite by suite. However, one step at a time. /Bruce