fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-05-19 04:58:08 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 2
mesa/src/mapi/Makefile.sources

50 lines
1 KiB
Text
Raw Normal View History

build: Move src/mapi/mapi/* to src/mapi/ Tested-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-and-Tested-by: Andreas Boll <andreas.boll.dev@gmail.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2013-01-21 10:27:25 -08:00
# src/mapi/Makefile.sources
mapi: Add a generic C dispatcher. The idea is to have an API generate a header using mapi_abi.py. The API can then use the header to build a dispatcher.
2010-04-23 16:07:47 +08:00
#
mapi: Clean up sources.mk. Rename MAPI_GLAPI_SOURCES to MAPI_UTIL_SOURCES. Rename macro MAPI_GLAPI_CURRENT to MAPI_MODE_UTIL. Update the comments to make it clear that mapi may be used in two ways and how.
2010-12-11 03:27:54 +08:00
# mapi may be used in several ways
mapi: Add a generic C dispatcher. The idea is to have an API generate a header using mapi_abi.py. The API can then use the header to build a dispatcher.
2010-04-23 16:07:47 +08:00
#
mapi: Clean up sources.mk. Rename MAPI_GLAPI_SOURCES to MAPI_UTIL_SOURCES. Rename macro MAPI_GLAPI_CURRENT to MAPI_MODE_UTIL. Update the comments to make it clear that mapi may be used in two ways and how.
2010-12-11 03:27:54 +08:00
# - In default mode, mapi implements the interface defined by mapi.h. To use
shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
2012-03-16 12:55:40 -04:00
# this mode, compile MAPI_FILES.
mapi: Clean up sources.mk. Rename MAPI_GLAPI_SOURCES to MAPI_UTIL_SOURCES. Rename macro MAPI_GLAPI_CURRENT to MAPI_MODE_UTIL. Update the comments to make it clear that mapi may be used in two ways and how.
2010-12-11 03:27:54 +08:00
#
# - In util mode, mapi provides utility functions for use with glapi. To use
shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
2012-03-16 12:55:40 -04:00
# this mode, compile MAPI_UTIL_FILES with MAPI_MODE_UTIL defined.
mapi: Add a new glapi.h implementation. The new implementation is based on mapi. No new script is needed. As noted in sources.mk, the way to use it is to compile MAPI_GLAPI_SOURCES with MAPI_MODE_GLAPI defined.
2010-12-11 03:33:42 +08:00
#
# - In glapi mode, mapi implements the interface defined by glapi.h. To use
shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
2012-03-16 12:55:40 -04:00
# this mode, compile MAPI_GLAPI_FILES with MAPI_MODE_GLAPI defined.
mapi: Add support for bridge mode. In bridge mode, mapi no longer implements glapi.h. It becomes a user of glapi.h. Imagine an app that uses both libGL.so and libGLESv2.so. There will be two copies of glapi in the app's memory. It is possible that _glapi_get_dispatch does not return what _glapi_set_dispatch set, if they access different copies of the global variables. The solution to this situation to build either one of the libraries as a bridge to the other. Or build both libraries as bridges to another shared glapi library.
2010-12-17 00:24:27 +08:00
#
# - In bridge mode, mapi provides entry points calling into glapi. To use
shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
2012-03-16 12:55:40 -04:00
# this mode, compile MAPI_BRIDGE_FILES with MAPI_MODE_BRIDGE defined.
mapi: Add mapi and share the code with glapi. Specifically, move all or most of glapi/glapi.c to mapi/u_current.c, glapi/glapi_execmem.c to mapi/u_execmem.c, glapi/glthread.[ch] to mapi/u_thread.[ch] and remove their dependencies on core Mesa headers.
2010-04-23 16:06:26 +08:00
shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
2012-03-16 12:55:40 -04:00
MAPI_UTIL_FILES = \
mapi: Build with subdir-objects.
2014-12-17 18:50:25 -08:00
u_current.c \
u_current.h \
u_execmem.c \
mapi: remove u_thread.h Just use c11 threads directly. Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: José Fonseca <jfonseca@vmware.com>
2015-03-04 19:17:57 -07:00
u_execmem.h
mapi: Add a generic C dispatcher. The idea is to have an API generate a header using mapi_abi.py. The API can then use the header to build a dispatcher.
2010-04-23 16:07:47 +08:00
glapi/build: Add headers to distribution. Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
2013-11-10 19:01:58 -08:00
MAPI_BRIDGE_FILES = \
mapi: Build with subdir-objects.
2014-12-17 18:50:25 -08:00
entry.c \
entry.h \
entry_x86-64_tls.h \
entry_x86_tls.h \
entry_x86_tsd.h \
mapi_tmp.h
glapi/build: Add headers to distribution. Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
2013-11-10 19:01:58 -08:00
MAPI_FILES = \
mapi: Build with subdir-objects.
2014-12-17 18:50:25 -08:00
entry.c \
mapi.c \
mapi.h \
stub.c \
stub.h \
table.c \
table.h \
shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
2012-03-16 12:55:40 -04:00
$(MAPI_UTIL_FILES)
mapi: Add a new glapi.h implementation. The new implementation is based on mapi. No new script is needed. As noted in sources.mk, the way to use it is to compile MAPI_GLAPI_SOURCES with MAPI_MODE_GLAPI defined.
2010-12-11 03:33:42 +08:00
shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
2012-03-16 12:55:40 -04:00
MAPI_GLAPI_FILES = \
mapi: Build with subdir-objects.
2014-12-17 18:50:25 -08:00
entry.c \
mapi_glapi.c \
stub.c \
stub.h \
table.c \
table.h \
shared-glapi: Convert to automake This fixes a build problem where EGL links to libgbm.la, which encodes a relative path to it's libglapi.so dependency. The relative path breaks when the linker tries to resolve it from src/egl/main instead of src/gbm. Typically we silently fall back to the system libglapi.so, which is wrong and breaks when there isn't one. Morale of the story: don't mix mklib and libtool.
2012-03-16 12:55:40 -04:00
$(MAPI_UTIL_FILES)
mapi: Add support for bridge mode. In bridge mode, mapi no longer implements glapi.h. It becomes a user of glapi.h. Imagine an app that uses both libGL.so and libGLESv2.so. There will be two copies of glapi in the app's memory. It is possible that _glapi_get_dispatch does not return what _glapi_set_dispatch set, if they access different copies of the global variables. The solution to this situation to build either one of the libraries as a bridge to the other. Or build both libraries as bridges to another shared glapi library.
2010-12-17 00:24:27 +08:00
Reference in a new issue Copy permalink