From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 0E7A5559A for ; Thu, 24 Jan 2019 19:11:39 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 622988E3DB; Thu, 24 Jan 2019 18:11:38 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 95D9F26366; Thu, 24 Jan 2019 18:11:37 +0000 (UTC) From: Aaron Conole To: Bruce Richardson Cc: Michael Santana , dev@dpdk.org, Thomas Monjalon , Ferruh Yigit References: <20190123220714.20763-1-msantana@redhat.com> <20190124093547.GA155072@bricha3-MOBL.ger.corp.intel.com> Date: Thu, 24 Jan 2019 13:11:36 -0500 In-Reply-To: <20190124093547.GA155072@bricha3-MOBL.ger.corp.intel.com> (Bruce Richardson's message of "Thu, 24 Jan 2019 09:35:48 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 24 Jan 2019 18:11:38 +0000 (UTC) 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:11:39 -0000 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. >> +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 >> + >> + 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!