GitLab

Without them, the build will fail on a system without the X headers with
a recent Mesa from the master branch. The EGL_CFLAGS_OTHER define the
MESA_EGL_NO_X11_HEADERS macro that guards the #includes of the X
headers.
Signed-off-by: Mircea Gherzan <mircea.gherzan@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>

CMake actually marks that we require six 1.4.0, however, I can't find
any packages anywhere for 1.4.0, and the lowest version I've seen
requested is 1.5.2.

This fixes requirements for working with six 1.5.2, and sets tox to use
1.5.2 (and a suitable version of mock). Primarily there are a few things
we're using that are not available: six.moves.getcwd, six.viewvalues,
six.python_2_unicode_compatible.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Tested-by: Brian Paul <brianp@vmware.com>

The generators have supported 3.x for some time, this now makes 3.x the
default, and falls back to 2.7

This has been tested with 3.5 and 2.7
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Acked-by: Jose Fonseca <jfonseca@vmware.com>

Matches Waffle's https://github.com/waffle-gl/waffle/commit/d15a83a453c87b445d8abf19d82668bca1a389d4

Trivial.

GCC 5.x and 4.x have different defaults, so it's better to explicitly
specify the target C standard to keep builds consistent.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Thanked-by: Kristian Høgsberg <krh@bitplanet.net>

It's been replaced by shader_runner.
Reviewed-by: Dylan Baker <dylanx.c.baker@intel.com>

MSVC defaults to 1MB stack size.  MinGW defaults to a larger value.
But in order to trap problems with excessive usage of the stack on
Windows we really want to match MSVC.
Reviewed-by: Brian Paul <brianp@vmware.com>

GLES tests require EGL support, so it only make sense that they are on
on systems which support EGL, which is Linux ATM.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

They can be quite distracting.
Reviewed-by: Brian Paul <brianp@vmware.com>

This reintroduces libpng support, but makes it optional since I only
plan to use it in an optional feature most people won't use.

This code is based on:

    commit ed98ddeb
    Author: Nicolai Haehnle <nhaehnle@gmail.com>
    Date:   Sun Mar 25 22:48:07 2007 +0200

        texline: Write screenshot using libpng
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

These are needed to pass tests, but they weren't being installed for
running out of tree. Fixes ~100 warns when running out of tree with
beignet. Trivial.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>

Void pointer arithmetic is not supported on MSVC, so passing
-Werror=pointer-arith will make it easier for everybody to catch this
sort of portability issues as the code is written.
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>

future_imports was added in Mako 0.8.0.

http://docs.makotemplates.org/en/latest/changelog.html#change-0.8.0

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89347Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>

six.PY2 was added in 1.4.0.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

Six is a module that provides a clean, standardized interface for
handling python2 and python3 from the same code base. This adds a
requirement on six as a build-time dependency, the plan is to use it
only for python generators (those called during build time)

While it certainly is possible to reimplement much of what six does
scratch and not add another python dependency, I think it's better to
just use six. For one thing a large number of python modules already
depend on six, so the chances are good that most people already have it
installed. Second, it's the de facto standard for supporting complex
code bases in 2 and 3, so it's familiar and many of the corner cases
have already been addressed.

This adds the necessary cmake boilerplate to ensure that six is
available. At this time I don't know of a specific version being
required, but I am currently using 1.9.0

v2: - update README with six dependency (Jordan)
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

Although the non-standard GCC syntax has some nice properties, for most
practical cases the standard C99 syntax is perfectly fine.  Particuarly
for printf-like macros, which pretty much account for most the uses of
variadic macros in piglit.

Unfortunately this will only be effective on newer GCC versions, due a
bug in GCC.  See comment for more details.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

MSVC 2013 does support C99 declarations after statements.  There were some
bugs before 2013 Update 4 but it there are no known issues with Update 4
so far.  And that's what we already require.

Trivial.

Trivial.

It has importants fixes to C parser.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>

Reviewed-by: Dylan Baker <dylanx.c.baker@intel.com>

Apparently find_package() and pkg_check_modules() return different
variables, while piglit still builds on my system without this patch if
fails on many other systems. This problem was doubly masked by the fact
that in the original series there is an additional patch to use waffle's
cmake config file instead of pkg_config. That patch is waiting for the
next cmake release.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>

The test generator for arb_shader_precision cannot be generated by numpy
< 1.6.2, probably due to numpy upstream bug #1675, which was fixed in
1.6.2.

bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88595Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Vinson Lee <vlee@freedesktop.org>

This patch adds 3 files, PythonModule.cmake, FindPythonMako.cmake and
FindPythonNumpy.cmake.

PythonModule provides a simple function for running python and parsing
the version strings, each FindPython*.cmake then just calls that
function, and then calls the find_package_handle_standard_args macro for
simple, standard finding. This is much more in line with how the core
cmake modules work, and makes is trivial to add additional python
modules with all of the standard cmake awesomeness like version
checking.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

This removes a bunch of code that we rolled for finding python
interpreters, and uses the cmake builtins.
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

This replaces WAFFLE_* with Waffle_*. It also replaces WAFFLE_LDFLAGS
with WAFFLE_LIBRARIES, which again is more cmake standard. This will be
used in follow on patches to use the cmake config module for waffle.

v2: - fix whitespace errors
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

We require python 2.7, but our error message still says that we require
2.6.

Trivial.
Signed-off-by: Dylan Baker <baker.dylan.c@gmail.com>

- Use find_path/find_library so one can see the variables on cmake-gui

- Provide better error message.
Reviewed-by: Brian Paul <brianp@vmware.com>

The version number must be manually on command line, hence this
version check is just an hindrance for Windows.
Reviewed-by: Brian Paul <brianp@vmware.com>

Instead of just MSVC builds.

Because pkg-config is not commonly available when compiling natively on
Windows, and gives the wrong results (the host package instead of target
package) when cross-compiling to Windows.
Reviewed-by: Brian Paul <brianp@vmware.com>

This will allow us to use waffle with its upcoming WGL support for
Windows. With that done, the final step to removing glut is to convert
piglit to use waffle for MacOS.

Current implementation does not have input handling/event loop, and as
such one needs to pass "-auto" when running individual tests, otherwise
the test will abort after being displayed for 8 seconds.

Waffle 1.5.0 is the first version that has WGL support.

TODO:
 - Add input handling (event_loop).

v2: Updated the instructions in the README.
v3: Update against upstream Waffle (no API breakage)
v4: s/Sleep/fprintf()+getchar()/ in the event_loop. Suggested by Jose.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com> (v1)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86045Signed-off-by: Vinson Lee <vlee@freedesktop.org>

As these are not supported on MSVC, not even MSVC 2013 since it only has
library support for C99, it doesn't actually support C99 syntax.

Suggested by Jan Vesely.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

Verified that cmake aborts with MSVS 2012.

https://bugs.freedesktop.org/show_bug.cgi?id=85528Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

If GBM is enabled, attempt to locate libcaca too.

If the test was not run with -auto, then use libcaca
to draw a text version of the test's results to the
console.

v2 (Ben): Rebase
Per Ken's comment the libcaca API may change at v1.0, but it's still not
there are 8 months. I propose we push this, and worry about libcaca
breakage later.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>

Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Eric Anholt <eric@anholt.net>

Python 2.6.6 was the final feature release of the 2.6 branch, it was
released in August 2010. Python 2.6.9 was the last security release, it
was released in October 2013. There is no support from upstream for 2.6,
either for bugs or security problems, OSX, linux, windows all have 2.7
available to them, as does VMWare in their environment.

Since no one any longer has a hard 2.6 requirement going to 2.7 seems
like a natural choice. It has more features, more modules, and better
3.x compatibility than 2.6 does.
Signed-off-by: Dylan Baker <baker.dylan.c@gmail.com>