StreetLight
/
libxkbcommon
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
libxkbcommon/.travis.yml

18 lines
697 B
YAML
Raw Normal View History

travis: remove --disable-x11 Looks like the CI machines can use Ubuntu 14.04, which has libxcb 1.10, which is new enough. Lets see if it works. Signed-off-by: Ran Benita <ran234@gmail.com>
2016-03-15 11:44:48 -06:00
sudo: required
dist: trusty
Add .travis.yml file This CI service https://travis-ci.org/ builds the project in several configurations, runs the tests, and if something fails it sends an email. Testing on some other systems is always good, and there don't seem to be any drawbacks to this, so why not. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-04-06 07:37:04 -06:00
language: c
before_install:
- sudo apt-get update -qq
travis: ensure all tests are valgrind-clean The tests will fail if they have any memory leaks or perform invalid accesses. Signed-off-by: Ran Benita <ran234@gmail.com>
2017-12-12 05:53:25 -07:00
- sudo apt-get -y install xutils-dev doxygen libxcb-xkb-dev python3-pip valgrind
build: add meson build system Meson is easier to maintain, much faster, encourages better practices, and is not built on a pile of shell scripts. The autotools build system is kept intact for now, in order to ease the migration. The intention is to remove it sooner rather than later, if all goes well. Run `meson build && mesonconf build` to see the configuration options for the new system. Conversion should be straightforward. Environment variables like CFLAGS work the same. If meson is used, xorg-util-macros is not required. In terms of functionality the two systems have about the same capabilities. Here are some differences I noticed: - Meson uses `-g` by default, autotools uses `-g -O2`. - In autotools the default behavior is to install both static and shared versions of the libraries. In meson the user must choose exactly one (using -Ddefault_library=static/shared). It is possible to workaround if needed (install twice...), but hopefully meson will add the option in the future. - Autotools has builtin ctags/cscope targets, meson doesn't. Easy to run the tools directly. - Meson has builtin benchmarks target. Handy. - Meson has builtin support for sanitizers/clang-analyzer/lto/pgo/ coverage etc. Also handy. Signed-off-by: Ran Benita <ran234@gmail.com>
2017-07-25 12:57:42 -06:00
- wget https://github.com/ninja-build/ninja/releases/download/v1.7.2/ninja-linux.zip && unzip ninja-linux.zip && sudo install ninja /usr/bin/
travis: pin meson to an older version so it works with Python 3.4 The CI image only has Python 3.4. It's a bit of a hassle to change this, so let's pin meson to the version before they bumped their requirement instead. I suppose it's not that bad in that it will guarantee compatibility with older meson over time. Signed-off-by: Ran Benita <ran234@gmail.com>
2018-06-23 14:17:07 -06:00
- sudo pip3 install meson==0.44.1
Add .travis.yml file This CI service https://travis-ci.org/ builds the project in several configurations, runs the tests, and if something fails it sends an email. Testing on some other systems is always good, and there don't seem to be any drawbacks to this, so why not. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-04-06 07:37:04 -06:00
compiler:
- gcc
- clang
travis: do the build out-of-tree To catch problems like the previous commit. Signed-off-by: Ran Benita <ran234@gmail.com>
2017-07-31 09:22:54 -06:00
script:
build: add meson build system Meson is easier to maintain, much faster, encourages better practices, and is not built on a pile of shell scripts. The autotools build system is kept intact for now, in order to ease the migration. The intention is to remove it sooner rather than later, if all goes well. Run `meson build && mesonconf build` to see the configuration options for the new system. Conversion should be straightforward. Environment variables like CFLAGS work the same. If meson is used, xorg-util-macros is not required. In terms of functionality the two systems have about the same capabilities. Here are some differences I noticed: - Meson uses `-g` by default, autotools uses `-g -O2`. - In autotools the default behavior is to install both static and shared versions of the libraries. In meson the user must choose exactly one (using -Ddefault_library=static/shared). It is possible to workaround if needed (install twice...), but hopefully meson will add the option in the future. - Autotools has builtin ctags/cscope targets, meson doesn't. Easy to run the tools directly. - Meson has builtin benchmarks target. Handy. - Meson has builtin support for sanitizers/clang-analyzer/lto/pgo/ coverage etc. Also handy. Signed-off-by: Ran Benita <ran234@gmail.com>
2017-07-25 12:57:42 -06:00
- mkdir autotools-build && pushd autotools-build && ../autogen.sh && make && make check && popd
travis: ensure all tests are valgrind-clean The tests will fail if they have any memory leaks or perform invalid accesses. Signed-off-by: Ran Benita <ran234@gmail.com>
2017-12-12 05:53:25 -07:00
- meson setup meson-build -Denable-wayland=false && pushd meson-build && ninja && meson test --print-errorlogs --wrap='valgrind --leak-check=full --track-origins=yes --error-exitcode=99' && popd