Introduce travis builds for github repositories
Checks
Commit Message
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 <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
---
.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
Comments
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 <aconole@redhat.com>
> Signed-off-by: Michael Santana <msantana@redhat.com>
> ---
> .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.
> +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.
Ideally, I suppose we'd have two setups - one with all the packages, the
other only with the minimum.
On Thu, Jan 24, 2019 at 09:35:48AM +0000, Bruce Richardson wrote:
> 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 <aconole@redhat.com>
> > Signed-off-by: Michael Santana <msantana@redhat.com>
> > ---
> > .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
> >
And on a more general note, this is great to see! The more automated CI
builds we can get, the better. Thanks.
/Bruce
Bruce Richardson <bruce.richardson@intel.com> 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 <aconole@redhat.com>
>> Signed-off-by: Michael Santana <msantana@redhat.com>
>> ---
>> .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!
23/01/2019 23:07, Michael Santana:
> +if [ "${NINJABUILD}" == "1" ]; then
> + meson build
> + ninja -C 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
Do we really want to support the "make system", given that it is going
to be deprecated this year?
On Thu, Jan 24, 2019 at 01:11:36PM -0500, Aaron Conole wrote:
> Bruce Richardson <bruce.richardson@intel.com> 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 <aconole@redhat.com>
> >> Signed-off-by: Michael Santana <msantana@redhat.com>
> >> ---
> >> .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
>
> 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 <aconole@redhat.com>
> Signed-off-by: Michael Santana <msantana@redhat.com>
> ---
> .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
> +else
> + make config T=x86_64-native-linuxapp-${CC}
Adding Arm builds would be helpful.
> + 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
> +
> +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
> +
> +sudo: false
> +
> +env:
> + - SHARED=1
> + - KERNEL=1
> + - NINJABUILD=1
> +
> +matrix:
> + include:
> + - compiler: clang
> +
> +script: ./.ci/${TRAVIS_OS_NAME}-build.sh
> +
> +notifications:
> + email:
> + recipients:
> + - test-report@dpdk.org
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 66104405e5..14a7bf1284 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -119,6 +119,12 @@ F: config/rte_config.h
> F: buildtools/gen-pmdinfo-cfile.sh
> F: buildtools/symlink-drivers-solibs.sh
>
> +Public CI
> +M: Aaron Conole <aconole@redhat.com>
> +M: Michael Santana <msantana@redhat.com>
> +F: .travis.yml
> +F: .ci/
> +
> ABI versioning
> M: Neil Horman <nhorman@tuxdriver.com>
> F: lib/librte_compat/
> diff --git a/doc/guides/contributing/patches.rst
> b/doc/guides/contributing/patches.rst
> index a64bb03683..745a11a67a 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -32,6 +32,9 @@ The mailing list for DPDK development is
> `dev@dpdk.org <http://mails.dpdk.org/ar Contributors will need to
> `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order
> to submit patches.
> It is also worth registering for the DPDK `Patchwork
> <http://patches.dpdk.org/project/dpdk/list/>`_
>
> +If you are using the GitHub service, you can link your repository to
> +the ``travis-ci.org`` build service. When you push patches to your
> repository, the travis service will automatically build your changes.
> +
> The development process requires some familiarity with the ``git`` version
> control system.
> Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further
> information.
>
> --
> 2.19.1
That's a good suggestion. I will look into it.
~Michael Santana
On Thu, Jan 24, 2019 at 2:27 PM Honnappa Nagarahalli <
Honnappa.Nagarahalli@arm.com> 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 <aconole@redhat.com>
> > Signed-off-by: Michael Santana <msantana@redhat.com>
> > ---
> > .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
> > +else
> > + make config T=x86_64-native-linuxapp-${CC}
> Adding Arm builds would be helpful.
>
> > + 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
> > +
> > +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
> > +
> > +sudo: false
> > +
> > +env:
> > + - SHARED=1
> > + - KERNEL=1
> > + - NINJABUILD=1
> > +
> > +matrix:
> > + include:
> > + - compiler: clang
> > +
> > +script: ./.ci/${TRAVIS_OS_NAME}-build.sh
> > +
> > +notifications:
> > + email:
> > + recipients:
> > + - test-report@dpdk.org
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 66104405e5..14a7bf1284 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -119,6 +119,12 @@ F: config/rte_config.h
> > F: buildtools/gen-pmdinfo-cfile.sh
> > F: buildtools/symlink-drivers-solibs.sh
> >
> > +Public CI
> > +M: Aaron Conole <aconole@redhat.com>
> > +M: Michael Santana <msantana@redhat.com>
> > +F: .travis.yml
> > +F: .ci/
> > +
> > ABI versioning
> > M: Neil Horman <nhorman@tuxdriver.com>
> > F: lib/librte_compat/
> > diff --git a/doc/guides/contributing/patches.rst
> > b/doc/guides/contributing/patches.rst
> > index a64bb03683..745a11a67a 100644
> > --- a/doc/guides/contributing/patches.rst
> > +++ b/doc/guides/contributing/patches.rst
> > @@ -32,6 +32,9 @@ The mailing list for DPDK development is
> > `dev@dpdk.org <http://mails.dpdk.org/ar Contributors will need to
> > `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_
> in order
> > to submit patches.
> > It is also worth registering for the DPDK `Patchwork
> > <http://patches.dpdk.org/project/dpdk/list/>`_
> >
> > +If you are using the GitHub service, you can link your repository to
> > +the ``travis-ci.org`` build service. When you push patches to your
> > repository, the travis service will automatically build your changes.
> > +
> > The development process requires some familiarity with the ``git``
> version
> > control system.
> > Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further
> > information.
> >
> > --
> > 2.19.1
>
>
Thomas Monjalon <thomas@monjalon.net> writes:
> 23/01/2019 23:07, Michael Santana:
>> +if [ "${NINJABUILD}" == "1" ]; then
>> + meson build
>> + ninja -C 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
>
> Do we really want to support the "make system", given that it is going
> to be deprecated this year?
I prefer to keep it for as long as 'make' is a supported build system.
Once 'make' is deprecated (or removed, either one), it should definitely
be dropped.
Currently, the meson build isn't as well documented (for example, the
linux build guide doesn't even refer to meson). So, most likely the
average developer who just wants to make a small contribution will run
'make' to build DPDK, and hasn't learned yet how to work with
meson/ninja.
Are there plans for which release will officially mark 'make' as
deprecated? If it will be 19.02, then let's drop this check in v2,
since it won't be around long enough to provide any benefit. If it will
be 19.05 or 19.08 then I think it probably will provide some value.
new file mode 100755
@@ -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
+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
new file mode 100755
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+python3.5 -m pip install --upgrade meson --user
new file mode 100644
@@ -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
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - SHARED=1
+ - KERNEL=1
+ - NINJABUILD=1
+
+matrix:
+ include:
+ - compiler: clang
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
+
+notifications:
+ email:
+ recipients:
+ - test-report@dpdk.org
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: lib/librte_compat/
@@ -32,6 +32,9 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to the ``travis-ci.org`` build service. When you push
+patches to your repository, the travis service will automatically build your changes.
+
The development process requires some familiarity with the ``git`` version control system.
Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.