gallium: introduce target directory
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
2010-03-08 19:11:35 +00:00
|
|
|
#######################################################################
|
|
|
|
|
# SConscript for xlib winsys
|
|
|
|
|
|
|
|
|
|
Import('*')
|
|
|
|
|
|
|
|
|
|
env = env.Clone()
|
|
|
|
|
|
|
|
|
|
env.Append(CPPPATH = [
|
2010-04-26 12:56:44 +08:00
|
|
|
'#/src/mapi',
|
gallium: introduce target directory
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
2010-03-08 19:11:35 +00:00
|
|
|
'#/src/mesa',
|
|
|
|
|
'#/src/mesa/main',
|
|
|
|
|
'#src/gallium/state_trackers/glx/xlib',
|
|
|
|
|
])
|
|
|
|
|
|
|
|
|
|
env.Append(CPPDEFINES = ['USE_XSHM'])
|
|
|
|
|
|
2010-11-01 13:30:22 +00:00
|
|
|
env.Prepend(LIBS = env['X11_LIBS'])
|
|
|
|
|
|
2010-03-09 17:08:36 +00:00
|
|
|
env.Prepend(LIBS = [
|
|
|
|
|
st_xlib,
|
|
|
|
|
ws_xlib,
|
|
|
|
|
trace,
|
2010-05-12 20:11:37 +01:00
|
|
|
rbug,
|
2010-11-10 23:42:17 +00:00
|
|
|
galahad,
|
2010-03-09 17:08:36 +00:00
|
|
|
glapi,
|
|
|
|
|
mesa,
|
|
|
|
|
glsl,
|
|
|
|
|
gallium,
|
2010-08-14 15:29:15 +01:00
|
|
|
'talloc'
|
2010-03-09 17:08:36 +00:00
|
|
|
])
|
|
|
|
|
|
gallium: introduce target directory
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
2010-03-08 19:11:35 +00:00
|
|
|
sources = [
|
|
|
|
|
'xlib.c',
|
|
|
|
|
]
|
|
|
|
|
|
2010-04-10 03:01:30 +01:00
|
|
|
if True:
|
gallium: introduce target directory
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
2010-03-08 19:11:35 +00:00
|
|
|
env.Append(CPPDEFINES = 'GALLIUM_SOFTPIPE')
|
2010-03-09 17:08:36 +00:00
|
|
|
env.Prepend(LIBS = [softpipe])
|
gallium: introduce target directory
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
2010-03-08 19:11:35 +00:00
|
|
|
|
2010-04-10 03:01:30 +01:00
|
|
|
if env['llvm']:
|
2010-04-10 02:41:39 +01:00
|
|
|
env.Append(CPPDEFINES = 'GALLIUM_LLVMPIPE')
|
|
|
|
|
env.Prepend(LIBS = [llvmpipe])
|
gallium: introduce target directory
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
2010-03-08 19:11:35 +00:00
|
|
|
|
2010-11-01 13:30:22 +00:00
|
|
|
if False:
|
|
|
|
|
# TODO: Detect Cell SDK
|
gallium: introduce target directory
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
2010-03-08 19:11:35 +00:00
|
|
|
env.Append(CPPDEFINES = 'GALLIUM_CELL')
|
2010-03-09 17:08:36 +00:00
|
|
|
env.Prepend(LIBS = [cell])
|
gallium: introduce target directory
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
2010-03-08 19:11:35 +00:00
|
|
|
|
|
|
|
|
# TODO: write a wrapper function http://www.scons.org/wiki/WrapperFunctions
|
|
|
|
|
libgl = env.SharedLibrary(
|
|
|
|
|
target ='GL',
|
|
|
|
|
source = sources,
|
|
|
|
|
)
|
|
|
|
|
|
2010-11-01 13:30:22 +00:00
|
|
|
if True:
|
|
|
|
|
# XXX: Only install this libGL.so if DRI not enabled
|
|
|
|
|
libgl = env.InstallSharedLibrary(libgl, version=(1, 5))
|
|
|
|
|
|
|
|
|
|
env.Alias('libgl-xlib', libgl)
|
