Currently makedepend is used by the Mesa Makefile-based build system,
but not required.
Unfortunately, not having it makes dependency resolution non-existent,
which is a source of subtle bugs, and is a rarely tested
configuration, since all Mesa developers likely have it installed.
Furthermore some idioms require dependency resolution to work at all,
such as making headers depend on generated files.
Code in glx/glxcmds.c which uses the XF86VIDMODE extension is already guarded. Also use
that guard to control inclusion of the xf86vmode.h header, and only enable that guard if the
XF86VIDMODE extension is found by pkgconfig.
This changes the behaviour on platforms which XF86VIDMODE exists, in that XF86VIDMODE used to
be mandatory, but is now optional.
Presumably other build systems are already arranging for -DXF86VIDMODE to be supplied to the
complier when glxcmds.c is compiled, so are not affected by this change
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Teach mklib/minstall more about cygwin so libraries are properly installed
Have mklib install the .dll into the lib/ staging directory as well
Have minstall install the .dll into PREFIX/bin at the same time as
installing the .dll.a link library into PREFIX/lib
mklib uses a '-' rather than a '.' as the separator before the version
number in library names on cygwin. Change the install globs so they match
library names like that.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Brian Paul <brianp@vmware.com>
I had used pkg-config from the Makefile because I didn't want to screw
around with the non-autoconf build, but that doesn't work because the
PKG_CONFIG_PATH or TALLOC_LIBS/TALLOC_CFLAGS that people set at
configure time needs to be respected and may not be present at build
time.
Bug #29585
This pulls in multiple i965 driver fixes which will help ensure better
testing coverage during development, and also gets past the conflicts
of the src/mesa/shader -> src/mesa/program move.
Conflicts:
src/mesa/Makefile
src/mesa/main/shaderapi.c
src/mesa/main/shaderobj.h
Fix this build error (in MesaGLUT-7.6.1)...
glut_cmap.c:23:66: error: X11/Xmu/StdCmap.h: No such file or directory
...by not preventing the cflags that pkg-config finds for glut dependencies
(including 'xmu') from being used.
Defining GLUT_CFLAGS before running the pkg-config prevents the
cflags found by pkg-config from being used.
This patch lets GLUT_CFLAGS that configure & pkg-config work
so hard to set actually get used.
Also make sure the generated configs/autoconf defines GLUT_CFLAGS
used in (at least) src/glut/glx/Makefile.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Merge all targets into targets/egl/. The target produces
egl_gallium_<HW>.so for each pipe driver and st_<API>.so for each client
APIs. This enables us to further merge egl_gallium_<HW>.so into
egl_gallium.so later.
When building OSMesa and xlib GL, the resulting OSMesa would be linked
against libGL instead of the internal mesa libraries. However, when
building with -fvisibility=hidden, some of the internal functions used
in OSMesa could not be resolved through libGL.
Instead, always build OSMesa standalone without linking against libGL.
This has the advantage that OSMesa is always built the same way, but it
means that disk space is wasted when libGL is installed since both
libraries will contain the internal objects.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Tested-by: Tom Fogal <tfogal@alumni.unh.edu>
This slightly reduces reduces cairo-gl firefox-talos-gfx runtime on my
Ironlake:
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] gl firefox-talos-gfx 38.236 38.383 0.43% 5/6
after:
[ 0] gl firefox-talos-gfx 37.799 38.203 0.39% 6/6
It turns out the cost of caching these objects and looking them up in
the cache again is greater than the cost of just computing the object
again, particularly when the overhead of having a separate BO to pin
is removed.
(Those that are paying close attention will note that this is a
reversal of the path I was moving the driver in a couple of years ago.
The major thing that has changed is that back then all state was
recomputed when we wrapped the streaming state buffer, including
recompiling our precious programs. Now, we're uncaching just the
objects that are cheap to compute, and retaining caching of expensive
objects)
The remaining programs are ones I've had difficulty finding a build
environment for to make the build system or are unit tests that should
probably live next to their code instead. Hopefully people can bring
over the build for remaining pieces they care about.
With the omit list gone, there are not too many differences in building
core mesa and ES overlay. Remove the mesa/es and build both of them in
src/mesa/Makefile.
The new target installs client API modules to EGL_DRIVER_INSTALL_DIR.
They are used by st/egl.
The client APIs are built from OpenGL and OpenVG state trackers. For
this to work, st/vega is modified to produce a static library,
libvega.a, instead. st/es is also not needed any more. It is removed
and --with-state-trackers=es is replaced by --enable-gles-overlay.
As st/egl now has its own client API modules, this solves the ABI issue
between st/egl and client APIs, as long as the client API modules are
distributed with st/egl. Plus, this allows st/egl to support OpenGL
with non-Gallium libGL.so.
Define <API>_LIB, <API>_LIB_NAME, <API>_LIB_GLOB, and some other
variables in the configs. Fix a typo in glesv1_cm.pc.in where an
inexistent variable is used.
Rename vgFooBar to vegaFooBar and use vgapi as the dispatcher. This
makes sure there is always a current context when the internal functions
are called. And eglGetProcAddress is finally supported.
Marek Olšák
Luca Barbieri
Chia-I Wu
Kristian Høgsberg
Jon TURNEY
Eric Anholt
nobled
Dave Airlie
Ian Romanick
Li Peng
Jakob Bornecrantz
John Hein
Jakob Bornecrantz
Corbin Simpson
Dan Nicholson
Vinson Lee