This is the supported way to do this, and should be more robust and
reliable.
v2: [Emil]
- enable backslash escapes
- don't hardcode the path
- pass the argument directly to meson
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (v1)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
The latter is the default these days and Travis will be removing sudo
soonish.
Flipping to xenial, allows us to remove a bunch of hacks we have. Plus
it prevents us from adding new ones, to workaround what seems like a
gcc/binutils bug. For example (from the upcoming meson build):
FAILED: ccache c++ -o src/gallium/targets/pipe-loader/pipe_r600.so ...
... src/util/libmesa_util.a ... /usr/lib/x86_64-linux-gnu/libz.so ...
src/util/libmesa_util.a(disk_cache.c.o): In function `deflate_and_write_to_disk':
_build/../src/util/disk_cache.c:746: undefined reference to `deflateInit_'
_build/../src/util/disk_cache.c:765: undefined reference to `deflate'
...
As we can see, even though libz.so is explicitly passed after the
object that requires it - the linker still fails to see the symbols.
Avoid all those situations - flip the switch.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Earlier commit flipped the default to python2 but forgot to update the
travis file. Props to pip caching things "worked" for a little while.
Fixes: f22ad5ef18 ("travis: use python3 for the autoconf builds")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
By the time Mesa 18.3 comes out (probably December '18), Meson 0.45 will
be 9 months old (March '18), so I think this is reasonable.
(btw, the currently-required Meson 0.44.1 was released less than 12 days
before 0.45, so we're really not bumping by much.)
Currently, the Meson versions in the major distributions are:
Arch: ships 0.47.2
CentOS: 7 ships 0.47.1
Debian: stable ships 0.37.1, so it hasn't been usable in a long time.
everything more recent ships 0.47.2
Fedora: 28 ships 0.45.1
FreeBSD: ships 0.46.1 (ports)
Gentoo: ships 0.46.1
OpenSUSE: 15 ships 0.46
Ubuntu: 18.04 ships 0.45.1
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
This reverts commit 855af9a5a2.
Turns out the python scripts are _not_ fully python 3 compatible.
As Ilia reported using get_xmlpool.py with LANG=C produces some weird
output - see the link for details.
Even though the issue was spotted with the autoconf build, it exposes a
genuine problem with the script (and lack of lang handling of the meson
build.)
https://lists.freedesktop.org/archives/mesa-dev/2018-August/203508.html
Meson now uses python3, so let's add a block for Autotools, move that
line into the buildsys-specific blocks, and set the correct version for
Meson.
Fixes: 2ee1c86d71 "meson: Build with Python 3"
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Like in the autotools target, make the list of drivers to be built in
each of the Meson targets explicit.
This will help to identify missing dependencies and other issues more
easily.
CC: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
In LLVM <6.0 we added explicitly libedit-dev, as it was required to
satisfy apt dependencies.
In LLVM 6.0, this is not required anymore, so let's remove it.
CC: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The ubuntu version provided by Travis is a bit old, and does not detect
correctly some C functions.
Use a more modern version through scons.
Reviewed-by: Andres Gomez <agomez@igalia.com>
Until now, the needed bits were wrongly included in linux/memfd.h
Since Travis' sys/syscall.h doesn't provide the SYS_memfd_create, we
generate that header manually, including the needed bits to avoid
compilation problems, as the ones observed after:
3228335b55 ("intel: aubinator: handle GGTT mappings")
v2: replace fixes commit with the first direct user of
syscall.h (Emil).
Fixes: 3228335b55 ("intel: aubinator: handle GGTT mappings")
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Juan A. Suarez Romero <jasuarez@igalia.com>
Cc: Dylan Baker <dylan.c.baker@intel.com>
Cc: Eric Engestrom <eric.engestrom@intel.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
I'd like to eventually drop support for the confusing "an array of
a single empty string is meant to be interpreted as an empty array", so
let's start by not using it anymore.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Fixes following dependency problem:
Native dependency xcb-dri3 found: NO found '1.11' but need: '>= 1.13'
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Fixes: c80c08e226 ("vulkan/wsi/x11: Add support for DRI3 v1.2")
On travis, for OSX, python2 from homebrew is pre-installed. per [1]:
python points to the macOS system Python (with no manual PATH modification)
python2 points to Homebrew’s Python 2.7.x (if installed)
python3 points to Homebrew’s Python 3.x (if installed)
pip doesn't exist
pip2 points to Homebrew’s Python 2.7.x’s pip (if installed)
pip3 points to Homebrew’s Python 3.x’s pip (if installed)
We will end up using 'python2' for building mesa.
Just use 'pip2' instead of 'pip', as that seems to work for all platforms on
travis.
[1] https://docs.brew.sh/Homebrew-and-Python.html
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Use a '|' YAML literal block to avoid the convoluted syntax needed to put
the entire conditional on a single line.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Simply disable gallium in non-gallium builds. For some reason the
gallium driver wont link on ubuntu 14.04 (it will on 16.04, debian
testing, and arch)
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
