Rather than having to keep track of all the build systems and their respecitve
definition of the mesa version, use a single top file VERSION. Every build
system is responsible for reading/parsing the file and using it
v2:
* remove useless bulletpoint from the documentation, suggested by Matt
* "Androing is Linux. Use '/' in stead of '\'", spotted by Chad V
* use cleaner code to get the version in scons, suggested by Chad V
v3:
* ensure leading and trailing whitespace characters are stripped while parsing
* android: handle GNU shell commands approapriately
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This patch unifies mesa's PACKAGE_VERSION on autotools, scons and
Android build systems.
Current behaviour is:
- Autotools uses 9.2.0 as PACKAGE_VERSION
- Scons and Android use 9.2-devel as PACKAGE_VERSION
With this patch all three build systems use 9.2.0-devel as
PACKAGE_VERSION.
Reviewed-by: Brian Paul <brianp@vmware.com>
It makes things too random, as settings for temporary trials get stored
permannently, and it make difficult to build several platforms from the
same tree.
So disable it, again.
GLES can be enabled by running scons with
$ scons gles=yes
When gles=yes is given, the build is changed in three ways. First,
libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes
DRI drivers and libEGL support and advertise GLES support. Second, GLES
libraries will be created. They are libGLESv1_CM, libGLESv2, and
libglapi. Last, libGL or opengl32 will link to libglapi. This change
is required as _glapi_* will be declared as __declspec(dllimport) in
libmesa.a on windows. libmesa.a expects those symbols to be defined in
another DLL. Due to this change to GL, GLES support is marked
experimental.
Note that GLES requires libxml2-python to generate some of its sources.
Use scons target and dependency system instead of ad-hoc options.
Now is simply a matter of naming what to build. For example:
scons libgl-xlib
scons libgl-gdi
scons graw-progs
scons llvmpipe
and so on. And there is also the possibility of scepcified subdirs, e.g.
scons src/gallium/drivers
If nothing is specified then everything will be build.
There might be some rough corners over the next days. Please bare with me.
Keith prefers a clean separation between graw applications and
implementations, where apps do not link libgallium.a but instead
get all functionality they need via graw interface.
Although this is not incompatible with late loading of graw drivers, it
it would make it very hard to maintain, as wrappers for every utility
symbol exposed in graw would have to be written or generated somehow.
Ideally scons should be able to work backwards from the list of
targets to figure out which drivers, state trackers and other
convenience libraries need to be built.
Certain headers, such as GL/glew.h, are in both the Mesa include and the
default installed include directories. On recent distros the needed
symbols can be found in both places. On older distros the installed
headers could be lacking symbols, so for a header that exists in both
places, the local one should be found first.
These are our reference software rasterizers. They can build everywhere
and are a precious debugging tool.
Making them always present immensily simplifies the scons logic.
If people want to avoid building it is still possible to pass
direcotries and target names to scons to narrow the build.
Now that draw depends on llvm it is very difficult to correctly handle
broken llvm installations. Either the user requests LLVM and it needs to
supply a working installation. Or it doesn't, and it gets no LLVM
accelerate pipe drivers.
Provides basic window system integration behind a simple interface,
allowing tests to be written without dependency on either the driver
or window system.
With a lot of work, could turn into something like glut for gallium.
There are so many state trackers and winsys that rely on it for debug
building, and trace can really build anywhere and is thin so there's no
point is making it an option.
Based on Xavier Chantry <chantry.xavier@gmail.com>'s patch:
"I also removed the trace check in xlib SConscript which is now useless, and
that script seems to deal with the cell driver, so I added cell in the check
for supported drivers."
Emil Velikov
Kenneth Graunke
Andreas Boll
José Fonseca
Chia-I Wu
Brian Paul
Jakob Bornecrantz
Keith Whitwell
Joakim Sindholt
Jakob Bornecrantz
Vinson Lee
Zack Rusin