gstreamer/gst-libs/gst/gl/x11/Makefile.am

## Process this file with automake to produce Makefile.in

noinst_LTLIBRARIES = libgstgl-x11.la

libgstgl_x11_la_SOURCES = \
	gstgldisplay_x11.c \
	gstglwindow_x11.c \
	xcb_event_source.c

noinst_HEADERS = \
	gstglwindow_x11.h \
	xcb_event_source.h

libgstgl_x11includedir = $(includedir)/gstreamer-@GST_API_VERSION@/gst/gl/x11
libgstgl_x11include_HEADERS = \
	gstgldisplay_x11.h

if USE_GLX
libgstgl_x11_la_SOURCES += gstglcontext_glx.c
noinst_HEADERS += gstglcontext_glx.h
endif

libgstgl_x11_la_CFLAGS = \
	-I$(top_srcdir)/gst-libs \
	-I$(top_builddir)/gst-libs \
	-DBUILDING_GST_GL \
	$(GL_CFLAGS) \
	$(GST_PLUGINS_BASE_CFLAGS) \
	$(GST_BASE_CFLAGS) \
	$(GST_CFLAGS)

libgstgl_x11_la_LDFLAGS = \
	$(GST_LIB_LDFLAGS) \
	$(GST_ALL_LDFLAGS)
[616/906] move window-specific code into seperate subfolders 2012-11-19 11:54:19 +00:00			`## Process this file with automake to produce Makefile.in`

			`noinst_LTLIBRARIES = libgstgl-x11.la`

			`libgstgl_x11_la_SOURCES = \`
[890/906] x11: add display subclass GstGLDisplayX11 holds the display connection and name. Each thread requires it's own X11 Display connection (initialised from name) due to the fact that we do not want to call XInitThreads(). Doing so would result in segfaults when integrating with GUI toolkits Gtk, Qt, etc. The Display connection is for OpenGL platforms where a constant display is required in order to share contexts (egl). In the case of a wrapped context (added later), we do not have GstGLWindow to retreive the display from so a 'master' connection is used instead. 2013-11-27 06:52:46 +00:00			`gstgldisplay_x11.c \`
[725/906] x11: use GMainContext/GMainLoop allows us to be reentrant https://bugzilla.gnome.org/show_bug.cgi?id=703445 2013-07-02 12:06:03 +00:00			`gstglwindow_x11.c \`
gl/x11: use xcb instead of libX11 - xcb is supposedly thread-safe! videotestsrc ! glimagesink now doesn't spuriously result in a 'call XInitThreads()' error however if anybody else is using X11, then XInitThreads() still needs to be called and multiple glimagesink's still need XInitThreads(). Everything still takes libX11 handles as they are compatible with the xcb variants. Unfortunately we cannot move fully over to xcb due to GLX being entirely based on Xlib. It's also impossible to transform a xcb_connection to a Display which means we require X11 handles. 2016-06-30 14:07:23 +00:00			`xcb_event_source.c`
[616/906] move window-specific code into seperate subfolders 2012-11-19 11:54:19 +00:00
[733/906] gl: Major header and include cleanup 2013-07-11 09:03:31 +00:00			`noinst_HEADERS = \`
[725/906] x11: use GMainContext/GMainLoop allows us to be reentrant https://bugzilla.gnome.org/show_bug.cgi?id=703445 2013-07-02 12:06:03 +00:00			`gstglwindow_x11.h \`
gl/x11: use xcb instead of libX11 - xcb is supposedly thread-safe! videotestsrc ! glimagesink now doesn't spuriously result in a 'call XInitThreads()' error however if anybody else is using X11, then XInitThreads() still needs to be called and multiple glimagesink's still need XInitThreads(). Everything still takes libX11 handles as they are compatible with the xcb variants. Unfortunately we cannot move fully over to xcb due to GLX being entirely based on Xlib. It's also impossible to transform a xcb_connection to a Display which means we require X11 handles. 2016-06-30 14:07:23 +00:00			`xcb_event_source.h`
[616/906] move window-specific code into seperate subfolders 2012-11-19 11:54:19 +00:00
[890/906] x11: add display subclass GstGLDisplayX11 holds the display connection and name. Each thread requires it's own X11 Display connection (initialised from name) due to the fact that we do not want to call XInitThreads(). Doing so would result in segfaults when integrating with GUI toolkits Gtk, Qt, etc. The Display connection is for OpenGL platforms where a constant display is required in order to share contexts (egl). In the case of a wrapped context (added later), we do not have GstGLWindow to retreive the display from so a 'master' connection is used instead. 2013-11-27 06:52:46 +00:00			`libgstgl_x11includedir = $(includedir)/gstreamer-@GST_API_VERSION@/gst/gl/x11`
			`libgstgl_x11include_HEADERS = \`
			`gstgldisplay_x11.h`

[616/906] move window-specific code into seperate subfolders 2012-11-19 11:54:19 +00:00			`if USE_GLX`
[794/906] context: add subclasses for the different platforms (egl, glx, wgl, etc) - most code taken from the Window subclasses - tested combinations: xEGL, GLX, Wayland+EGL, Cocoa (under GNUStep), WGL (Wine) 2013-08-15 07:09:04 +00:00			`libgstgl_x11_la_SOURCES += gstglcontext_glx.c`
			`noinst_HEADERS += gstglcontext_glx.h`
[616/906] move window-specific code into seperate subfolders 2012-11-19 11:54:19 +00:00			`endif`

			`libgstgl_x11_la_CFLAGS = \`
[792/906] build: use our own in tree headers before system ones allows us to develop against the tree rather than what may be installed 2013-08-13 10:10:56 +00:00			`-I$(top_srcdir)/gst-libs \`
gl: fix out-of-source builds. Always use the locally generated <gst/gl/gstglconfig.h> file. Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com> 2014-03-24 16:33:00 +00:00			`-I$(top_builddir)/gst-libs \`
libs: fix API export/import and 'inconsistent linkage' on MSVC For each lib we build export its own API in headers when we're building it, otherwise import the API from the headers. This fixes linker warnings on Windows when building with MSVC. The problem was that we had defined all GST__API decorators unconditionally to GST_EXPORT. This was intentional and only supposed to be temporary, but caused linker warnings because we tell the linker that we want to export all symbols even those from externall DLLs, and when the linker notices that they were in external DLLS and not present locally it warns. What we need to do when building each library is: export the library's own symbols and import all other symbols. To this end we define e.g. BUILDING_GST_FOO and then we define the GST_FOO_API decorator either to export or to import symbols depending on whether BUILDING_GST_FOO is set or not. That way external users of each library API automatically get the import. While we're at it, add new GST_API_EXPORT in config.h and use that for GST__API decorators instead of GST_EXPORT. The right export define depends on the toolchain and whether we're using -fvisibility=hidden or not, so it's better to set it to the right thing directly than hard-coding a compiler whitelist in the public header. We put the export define into config.h instead of passing it via the command line to the compiler because it might contain spaces and brackets and in the autotools scenario we'd have to pass that through multiple layers of plumbing and Makefile/shell escaping and we're just not going to be that lucky. The export define is only used if we're compiling our lib, not by external users of the lib headers, so it's not a problem to put it into config.h Also, this means all .c files of libs need to include config.h to get the export marker defined, so fix up a few that didn't include config.h. This commit depends on a common submodule commit that makes gst-glib-gen.mak add an #include "config.h" to generated enum/marshal .c files for the autotools build. https://bugzilla.gnome.org/show_bug.cgi?id=797185 2018-04-28 13:50:11 +00:00			`-DBUILDING_GST_GL \`
[616/906] move window-specific code into seperate subfolders 2012-11-19 11:54:19 +00:00			`$(GL_CFLAGS) \`
			`$(GST_PLUGINS_BASE_CFLAGS) \`
			`$(GST_BASE_CFLAGS) \`
[792/906] build: use our own in tree headers before system ones allows us to develop against the tree rather than what may be installed 2013-08-13 10:10:56 +00:00			`$(GST_CFLAGS)`
[616/906] move window-specific code into seperate subfolders 2012-11-19 11:54:19 +00:00
			`libgstgl_x11_la_LDFLAGS = \`
			`$(GST_LIB_LDFLAGS) \`
[695/906] build: remove libtool warning about -version-info not used in convenience libraries 2013-06-04 12:18:51 +00:00			`$(GST_ALL_LDFLAGS)`