AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
ef0956f810
gtk2/gsk/Makefile.am

333 lines
10 KiB
Makefile
Raw Normal View History

gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
include $(top_srcdir)/Makefile.decl
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
GSK_CFLAG_DEFINES = \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
-DG_LOG_DOMAIN=\"Gsk\" \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
-DG_LOG_USE_STRUCTURED=1 \
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
-DGSK_COMPILATION
AM_CPPFLAGS = \
$(GSK_CFLAG_DEFINES) \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
-I$(top_srcdir) \
-I$(top_srcdir)/gdk \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
-I$(top_builddir) \
-I$(top_builddir)/gsk \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
$(GTK_DEBUG_FLAGS) \
$(GTK_WARN_FLAGS) \
$(GSK_DEP_CFLAGS)
BUILT_SOURCES =
CLEANFILES =
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
DISTCLEANFILES =
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
noinst_LTLIBRARIES =
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
if HAVE_VULKAN
Fix distcheck
2016-12-21 19:12:17 +00:00
gsk_private_vulkan_source_h = \
vulkan: Add GskVulkanBlendPipeline So far that's just a simple pipeline that doesn't do anything.
2016-12-17 23:57:37 +00:00
gskvulkanblendpipelineprivate.h \
vulkan: Add shader for border rendering
2017-01-10 13:59:20 +00:00
gskvulkanborderpipelineprivate.h \
vulkan: Add support for unblurred box-shadow
2017-01-18 03:07:09 +00:00
gskvulkanboxshadowpipelineprivate.h \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanbufferprivate.h \
gsk: Add GskVulkanClip This is now tracking the clips added by the clip nodes. If any particular node can't deal with a clip, it falls back to Cairo rendering. But if it can, it will render it directly.
2016-12-23 20:36:17 +00:00
gskvulkanclipprivate.h \
vulkan: Split color and blend pipelines
2016-12-18 01:18:01 +00:00
gskvulkancolorpipelineprivate.h \
vulkan: Split out command pool This way we can pass the command pool around. And that allows us to allocate and submitcustom buffers. And that is necessary to make staging images work.
2016-12-16 05:10:24 +00:00
gskvulkancommandpoolprivate.h \
vulkan: Handle opacity nodes Well, "handle" them actually. We still draw the node's child using Cairo, but we apply the opacity manually now.
2016-12-30 05:46:34 +00:00
gskvulkaneffectpipelineprivate.h \
vulkan: Make GskVulkanRenderer work We now create a Cairo renderer, render to an image surface and upload and retnder it with Vulkan.
2016-12-06 13:42:46 +00:00
gskvulkanimageprivate.h \
vulkan: Handle opacity nodes Well, "handle" them actually. We still draw the node's child using Cairo, but we apply the opacity manually now.
2016-12-30 05:46:34 +00:00
gskvulkanlineargradientpipelineprivate.h \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanmemoryprivate.h \
gskvulkanpipelineprivate.h \
vulkan: Add infrastructure for push constants THe code includes fragment push constants for colors, but that code is so far unused.
2016-12-14 06:21:21 +00:00
gskvulkanpushconstantsprivate.h \
vulkan: Add GskVulkanRender object This is refactoring work. GskVulkanRender is supposed to be the global object for a render operation, ie GskVulkanRenderer.render() will create this object for what it does. The object will be split into stages that perform the operations necessary to create a drawing.
2016-12-07 13:50:52 +00:00
gskvulkanrenderprivate.h \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanrendererprivate.h \
vulkan: Add GskVulkanRenderPass And move the actual rendering code there. A RenderPass is a collection of operations on the same target that get executed one after another. It roughly targets VkRenderPass or rather the subpasses of a VkRenderPass. For now, only the infrastructure is there. No real stuff is happening.
2016-12-08 12:26:36 +00:00
gskvulkanrenderpassprivate.h \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanshaderprivate.h
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
gsk_private_vulkan_source_c = \
vulkan: Add GskVulkanBlendPipeline So far that's just a simple pipeline that doesn't do anything.
2016-12-17 23:57:37 +00:00
gskvulkanblendpipeline.c \
vulkan: Add shader for border rendering
2017-01-10 13:59:20 +00:00
gskvulkanborderpipeline.c \
vulkan: Add support for unblurred box-shadow
2017-01-18 03:07:09 +00:00
gskvulkanboxshadowpipeline.c \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanbuffer.c \
gsk: Add GskVulkanClip This is now tracking the clips added by the clip nodes. If any particular node can't deal with a clip, it falls back to Cairo rendering. But if it can, it will render it directly.
2016-12-23 20:36:17 +00:00
gskvulkanclip.c \
vulkan: Split color and blend pipelines
2016-12-18 01:18:01 +00:00
gskvulkancolorpipeline.c \
vulkan: Split out command pool This way we can pass the command pool around. And that allows us to allocate and submitcustom buffers. And that is necessary to make staging images work.
2016-12-16 05:10:24 +00:00
gskvulkancommandpool.c \
vulkan: Handle opacity nodes Well, "handle" them actually. We still draw the node's child using Cairo, but we apply the opacity manually now.
2016-12-30 05:46:34 +00:00
gskvulkaneffectpipeline.c \
vulkan: Handle linear gradients Note: We interpolate premultiplied colors as per the CSS spec. This i different from Cairo, which interpolates unpremultiplied. So in testcases with translucent gradients, it's actually Cairo that is wrong.
2016-12-26 16:11:13 +00:00
gskvulkanlineargradientpipeline.c \
vulkan: Make GskVulkanRenderer work We now create a Cairo renderer, render to an image surface and upload and retnder it with Vulkan.
2016-12-06 13:42:46 +00:00
gskvulkanimage.c \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanmemory.c \
gskvulkanpipeline.c \
vulkan: Add infrastructure for push constants THe code includes fragment push constants for colors, but that code is so far unused.
2016-12-14 06:21:21 +00:00
gskvulkanpushconstants.c \
vulkan: Add GskVulkanRender object This is refactoring work. GskVulkanRender is supposed to be the global object for a render operation, ie GskVulkanRenderer.render() will create this object for what it does. The object will be split into stages that perform the operations necessary to create a drawing.
2016-12-07 13:50:52 +00:00
gskvulkanrender.c \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanrenderer.c \
vulkan: Add GskVulkanRenderPass And move the actual rendering code there. A RenderPass is a collection of operations on the same target that get executed one after another. It roughly targets VkRenderPass or rather the subpasses of a VkRenderPass. For now, only the infrastructure is there. No real stuff is happening.
2016-12-08 12:26:36 +00:00
gskvulkanrenderpass.c \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanshader.c
vulkan: Add shader for border rendering
2017-01-10 13:59:20 +00:00
gsk_private_vulkan_include_shaders = \
vulkan: Add a clip.frag.glsl include This include is supposed to handle clipping for the different clipping methods. So far, we only use it in the rounded rect cases.
2017-01-17 04:36:03 +00:00
resources/vulkan/clip.frag.glsl \
vulkan: Add clip.vert.glsl Implement clipping the same way as in the last commit for the fragment shaders.
2017-01-17 04:50:52 +00:00
resources/vulkan/clip.vert.glsl \
vulkan: Move push constants into their own header This is the first step towards easing maintenance of the Vulkan shaders by moving common code into headers.
2017-01-17 01:20:08 +00:00
resources/vulkan/constants.glsl \
vulkan: Add shader for border rendering
2017-01-10 13:59:20 +00:00
resources/vulkan/rounded-rect.glsl
vulkan: Generate clip shaders from same source Instead of having 3 different shaders for the different clipping versions, just have one shader and use a preprocessor define to use different clip functions. That preprocessor define is set in the Makefile. Also use foo.frag and foo.vert as the file extensions instead of using foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as extension.
2017-01-17 05:15:03 +00:00
gsk_private_vulkan_fragment_shaders = \
resources/vulkan/blend.frag \
resources/vulkan/border.frag \
resources/vulkan/color.frag \
resources/vulkan/color-matrix.frag \
vulkan: Add support for unblurred box-shadow
2017-01-18 03:07:09 +00:00
resources/vulkan/inset-shadow.frag \
resources/vulkan/linear.frag \
resources/vulkan/outset-shadow.frag
vulkan: Generate clip shaders from same source Instead of having 3 different shaders for the different clipping versions, just have one shader and use a preprocessor define to use different clip functions. That preprocessor define is set in the Makefile. Also use foo.frag and foo.vert as the file extensions instead of using foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as extension.
2017-01-17 05:15:03 +00:00
gsk_private_vulkan_vertex_shaders = \
resources/vulkan/blend.vert \
resources/vulkan/border.vert \
resources/vulkan/color.vert \
resources/vulkan/color-matrix.vert \
vulkan: Add support for unblurred box-shadow
2017-01-18 03:07:09 +00:00
resources/vulkan/inset-shadow.vert \
resources/vulkan/linear.vert \
resources/vulkan/outset-shadow.vert
gsk: Have variables for resources Instead of relying on --generate-dependencies and the resource file, actually list the resources in Make variables. Fixes make not building new shaders because they're not inside the resource file.
2017-01-05 12:11:02 +00:00
gsk_private_vulkan_shaders = \
vulkan: Generate clip shaders from same source Instead of having 3 different shaders for the different clipping versions, just have one shader and use a preprocessor define to use different clip functions. That preprocessor define is set in the Makefile. Also use foo.frag and foo.vert as the file extensions instead of using foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as extension.
2017-01-17 05:15:03 +00:00
$(gsk_private_vulkan_fragment_shaders) \
$(gsk_private_vulkan_vertex_shaders)
gsk: Have variables for resources Instead of relying on --generate-dependencies and the resource file, actually list the resources in Make variables. Fixes make not building new shaders because they're not inside the resource file.
2017-01-05 12:11:02 +00:00
gsk_private_vulkan_compiled_shaders = \
vulkan: Generate clip shaders from same source Instead of having 3 different shaders for the different clipping versions, just have one shader and use a preprocessor define to use different clip functions. That preprocessor define is set in the Makefile. Also use foo.frag and foo.vert as the file extensions instead of using foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as extension.
2017-01-17 05:15:03 +00:00
$(gsk_private_vulkan_fragment_shaders:.frag=.frag.spv) \
$(gsk_private_vulkan_vertex_shaders:.vert=.vert.spv) \
$(gsk_private_vulkan_fragment_shaders:.frag=-clip.frag.spv) \
$(gsk_private_vulkan_vertex_shaders:.vert=-clip.vert.spv) \
$(gsk_private_vulkan_fragment_shaders:.frag=-clip-rounded.frag.spv) \
$(gsk_private_vulkan_vertex_shaders:.vert=-clip-rounded.vert.spv)
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
endif
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk_public_source_h = \
gskenums.h \
gskrenderer.h \
gskrendernode.h \
gsk: Add GskRoundedRect It's essentially a port of GtkRoundedBox to graphene.
2016-12-13 18:02:12 +00:00
gskroundedrect.h \
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
gsktexture.h \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsktypes.h
gsk_private_source_h = \
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
$(gsk_private_vulkan_source_h) \
gsk: Move gtk/gtkcairoblur.c to gsk/gskcairoblur.c
2016-12-18 20:45:15 +00:00
gskcairoblurprivate.h \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskcairorendererprivate.h \
gskdebugprivate.h \
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
gskgldriverprivate.h \
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
gskglprofilerprivate.h \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskglrendererprivate.h \
gsk: Add ShaderBuilder GskShaderBuilder is an ancillary, private type that deals with the internals of taking GLSL shaders from resources and building them, with the additional feature of being able to compose shaders from a common preamble, as well as adding conditional defines (useful for enabling debugging code in the shaders themselves).
2016-07-03 19:04:40 +00:00
gskprivate.h \
gsk: Add profiler object The GskProfiler holds counters and timers, and will be used by the renderer implementations to acquire frame timings.
2016-08-03 15:48:49 +00:00
gskprofilerprivate.h \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskrendererprivate.h \
gskrendernodeprivate.h \
gsk: Add GskRoundedRect It's essentially a port of GtkRoundedBox to graphene.
2016-12-13 18:02:12 +00:00
gskroundedrectprivate.h \
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
gskshaderbuilderprivate.h \
gsktextureprivate.h
gsk: Have variables for resources Instead of relying on --generate-dependencies and the resource file, actually list the resources in Make variables. Fixes make not building new shaders because they're not inside the resource file.
2017-01-05 12:11:02 +00:00
gsk_private_source_shaders = \
gsk: Don't use wildcards Explicitly list all the shaders, so new ones get picked up properly and cause the resource file to be regenerated (due to Makefile.am changing).
2017-01-05 12:37:58 +00:00
resources/glsl/blend.fs.glsl \
resources/glsl/blend.vs.glsl \
resources/glsl/blit.fs.glsl \
resources/glsl/blit.vs.glsl \
resources/glsl/es2_common.fs.glsl \
resources/glsl/es2_common.vs.glsl \
resources/glsl/gl3_common.fs.glsl \
resources/glsl/gl3_common.vs.glsl \
resources/glsl/gl_common.fs.glsl \
resources/glsl/gl_common.vs.glsl
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
gsk_public_source_c = \
gskrenderer.c \
gskrendernode.c \
gsk: Split render node subclasses out into their own file
2016-12-11 01:59:47 +00:00
gskrendernodeimpl.c \
gsk: Add GskRoundedRect It's essentially a port of GtkRoundedBox to graphene.
2016-12-13 18:02:12 +00:00
gskroundedrect.c \
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
gsktexture.c
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk_private_source_c = \
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
$(gsk_private_vulkan_source_c) \
gsk: Move gtk/gtkcairoblur.c to gsk/gskcairoblur.c
2016-12-18 20:45:15 +00:00
gskcairoblur.c \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskcairorenderer.c \
gskdebug.c \
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
gskgldriver.c \
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
gskglprofiler.c \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskglrenderer.c \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
gskprivate.c \
gsk: Add profiler object The GskProfiler holds counters and timers, and will be used by the renderer implementations to acquire frame timings.
2016-08-03 15:48:49 +00:00
gskprofiler.c \
gsk: Add ShaderBuilder GskShaderBuilder is an ancillary, private type that deals with the internals of taking GLSL shaders from resources and building them, with the additional feature of being able to compose shaders from a common preamble, as well as adding conditional defines (useful for enabling debugging code in the shaders themselves).
2016-07-03 19:04:40 +00:00
gskshaderbuilder.c
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
gsk_built_source_h = \
gskenumtypes.h \
gskresources.h
gsk_built_source_c = \
gskenumtypes.c \
gskresources.c
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
all_sources = \
$(gsk_public_source_h) \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
$(gsk_public_source_c) \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
$(gsk_private_source_h) \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
$(gsk_private_source_c)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
BUILT_SOURCES += $(gsk_built_source_h) $(gsk_built_source_c) gsk.resources.xml
gskenumtypes.h: $(gsk_public_source_h) gskenumtypes.h.template
$(AM_V_GEN) $(GLIB_MKENUMS) --template $(filter %.template,$^) $(filter-out %.template,$^) > \
gskenumtypes.h.tmp && \
mv gskenumtypes.h.tmp gskenumtypes.h
gskenumtypes.c: $(gsk_public_source_h) gskenumtypes.c.template
$(AM_V_GEN) $(GLIB_MKENUMS) --template $(filter %.template,$^) $(filter-out %.template,$^) > \
gskenumtypes.c.tmp && \
mv gskenumtypes.c.tmp gskenumtypes.c
EXTRA_DIST += gskenumtypes.h.template gskenumtypes.c.template
DISTCLEANFILES += gskenumtypes.h gskenumtypes.c
build: List resource files explicitly This way, we ensure that files that are built during make always get properly listed. And we ensure that creating the resources actually depends on them.
2017-01-11 14:17:49 +00:00
resource_files = \
$(gsk_private_source_shaders) \
$(gsk_private_vulkan_compiled_shaders) \
$(gsk_private_vulkan_shaders)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
vulkan: Generate clip shaders from same source Instead of having 3 different shaders for the different clipping versions, just have one shader and use a preprocessor define to use different clip functions. That preprocessor define is set in the Makefile. Also use foo.frag and foo.vert as the file extensions instead of using foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as extension.
2017-01-17 05:15:03 +00:00
resources/vulkan/%-clip-rounded.frag.spv: resources/vulkan/%.frag
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
@if test -z "$(GLSLC)"; then echo "Missing glslc. See https://github.com/google/shaderc"; exit 1; fi
vulkan: Generate clip shaders from same source Instead of having 3 different shaders for the different clipping versions, just have one shader and use a preprocessor define to use different clip functions. That preprocessor define is set in the Makefile. Also use foo.frag and foo.vert as the file extensions instead of using foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as extension.
2017-01-17 05:15:03 +00:00
$(AM_V_GEN) $(GLSLC) -fshader-stage=fragment -DCLIP_ROUNDED_RECT -o $@.tmp $< && mv $@.tmp $@
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
vulkan: Generate clip shaders from same source Instead of having 3 different shaders for the different clipping versions, just have one shader and use a preprocessor define to use different clip functions. That preprocessor define is set in the Makefile. Also use foo.frag and foo.vert as the file extensions instead of using foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as extension.
2017-01-17 05:15:03 +00:00
resources/vulkan/%-clip-rounded.vert.spv: resources/vulkan/%.vert
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
@if test -z "$(GLSLC)"; then echo "Missing glslc. See https://github.com/google/shaderc"; exit 1; fi
vulkan: Generate clip shaders from same source Instead of having 3 different shaders for the different clipping versions, just have one shader and use a preprocessor define to use different clip functions. That preprocessor define is set in the Makefile. Also use foo.frag and foo.vert as the file extensions instead of using foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as extension.
2017-01-17 05:15:03 +00:00
$(AM_V_GEN) $(GLSLC) -fshader-stage=vertex -DCLIP_ROUNDED_RECT -o $@.tmp $< && mv $@.tmp $@
resources/vulkan/%-clip.frag.spv: resources/vulkan/%.frag
@if test -z "$(GLSLC)"; then echo "Missing glslc. See https://github.com/google/shaderc"; exit 1; fi
$(AM_V_GEN) $(GLSLC) -fshader-stage=fragment -DCLIP_RECT -o $@.tmp $< && mv $@.tmp $@
resources/vulkan/%-clip.vert.spv: resources/vulkan/%.vert
@if test -z "$(GLSLC)"; then echo "Missing glslc. See https://github.com/google/shaderc"; exit 1; fi
$(AM_V_GEN) $(GLSLC) -fshader-stage=vertex -DCLIP_RECT -o $@.tmp $< && mv $@.tmp $@
resources/vulkan/%.frag.spv: resources/vulkan/%.frag
@if test -z "$(GLSLC)"; then echo "Missing glslc. See https://github.com/google/shaderc"; exit 1; fi
$(AM_V_GEN) $(GLSLC) -fshader-stage=fragment -DCLIP_NONE -o $@.tmp $< && mv $@.tmp $@
resources/vulkan/%.vert.spv: resources/vulkan/%.vert
@if test -z "$(GLSLC)"; then echo "Missing glslc. See https://github.com/google/shaderc"; exit 1; fi
$(AM_V_GEN) $(GLSLC) -fshader-stage=vertex -DCLIP_NONE -o $@.tmp $< && mv $@.tmp $@
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk.resources.xml: Makefile.am
$(AM_V_GEN) echo "<?xml version='1.0' encoding='UTF-8'?>" > $@; \
echo "<gresources>" >> $@; \
echo " <gresource prefix='/org/gtk/libgsk'>" >> $@; \
gsk: Have variables for resources Instead of relying on --generate-dependencies and the resource file, actually list the resources in Make variables. Fixes make not building new shaders because they're not inside the resource file.
2017-01-05 12:11:02 +00:00
for f in $(gsk_private_source_shaders); do \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
n=`basename $$f`; \
echo " <file alias='glsl/$$n'>resources/glsl/$$n</file>" >> $@; \
done; \
gsk: Have variables for resources Instead of relying on --generate-dependencies and the resource file, actually list the resources in Make variables. Fixes make not building new shaders because they're not inside the resource file.
2017-01-05 12:11:02 +00:00
for f in $(gsk_private_vulkan_compiled_shaders); do \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
n=`basename $$f`; \
echo " <file alias='vulkan/$$n'>resources/vulkan/$$n</file>" >> $@; \
done; \
gsk: Have variables for resources Instead of relying on --generate-dependencies and the resource file, actually list the resources in Make variables. Fixes make not building new shaders because they're not inside the resource file.
2017-01-05 12:11:02 +00:00
for f in $(gsk_private_vulkan_shaders); do \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
n=`basename $$f`; \
echo " <file alias='vulkan/$$n'>resources/vulkan/$$n</file>" >> $@; \
done; \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
echo " </gresource>" >> $@; \
echo "</gresources>" >> $@
build: List resource files explicitly This way, we ensure that files that are built during make always get properly listed. And we ensure that creating the resources actually depends on them.
2017-01-11 14:17:49 +00:00
gskresources.h: gsk.resources.xml $(resource_files)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
$(AM_V_GEN) $(GLIB_COMPILE_RESOURCES) $< \
--target=$@ --sourcedir=$(srcdir) --c-name _gsk --generate-header --manual-register
gskresources.c: gsk.resources.xml $(resource_files)
$(AM_V_GEN) $(GLIB_COMPILE_RESOURCES) $< \
--target=$@ --sourcedir=$(srcdir) --c-name _gsk --generate-source --manual-register
vulkan: Add shader for border rendering
2017-01-10 13:59:20 +00:00
EXTRA_DIST += $(resource_files) $(gsk_private_vulkan_include_shaders)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
CLEANFILES += gsk.resources.xml
DISTCLEANFILES += gskresources.h gskresources.c
libgsk_4_la_SOURCES = $(all_sources)
nodist_libgsk_4_la_SOURCES = $(gsk_built_source_h) $(gsk_built_source_c)
libgsk_4_la_CFLAGS = $(AM_CFLAGS) $(GDK_HIDDEN_VISIBILITY_CFLAGS)
libgsk_4_la_LIBADD = $(GSK_DEP_LIBS) $(top_builddir)/gdk/libgdk-4.la
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
noinst_LTLIBRARIES += libgsk-4.la
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskincludedir = $(includedir)/gtk-4.0/gsk
gskinclude_HEADERS = $(gsk_public_source_h) gskenumtypes.h gsk.h
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
-include $(INTROSPECTION_MAKEFILE)
INTROSPECTION_GIRS =
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
INTROSPECTION_SCANNER_ENV = CC="$(CC)"
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
INTROSPECTION_SCANNER_ARGS = \
--add-include-path=../gdk \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
--add-include-path=../gsk \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
--warn-all
INTROSPECTION_COMPILER_ARGS = \
--includedir=$(srcdir) \
--includedir=. \
--includedir=../gdk
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
if HAVE_INTROSPECTION
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
introspection_files = $(gsk_public_source_h) $(gsk_public_source_c)
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
gsk: ensure libgsk-4.la before running g-ir-scanner https://bugzilla.gnome.org/show_bug.cgi?id=775410
2016-11-30 15:06:43 +00:00
Gsk-noinst-4.0.gir: libgsk-4.la Makefile
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
Gsk_noinst_4_0_gir_SCANNERFLAGS = \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
--add-include-path=$(top_builddir)/gdk \
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
--include-uninstalled=$(top_builddir)/gdk/Gdk-noinst-4.0.gir \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
--c-include="gsk/gsk.h"
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
Gsk_noinst_4_0_gir_LIBS = libgsk-4.la
Gsk_noinst_4_0_gir_FILES = $(introspection_files)
Gsk_noinst_4_0_gir_CFLAGS = $(AM_CPPFLAGS) $(GDK_HIDDEN_VISIBILITY_CFLAGS)
Gsk_noinst_4_0_gir_EXPORT_PACKAGES = gsk-4.0
Gsk_noinst_4_0_gir_INCLUDES = GObject-2.0 cairo-1.0 Graphene-1.0
INTROSPECTION_GIRS += Gsk-noinst-4.0.gir
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
noinst_DATA = $(INTROSPECTION_GIRS)
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
build: Clean the uninstalled introspection GIR files We need to remove them from the build when cleaning them. Additionally, this automatically adds them to the Git ignore file.
2016-10-31 16:30:10 +00:00
CLEANFILES += $(INTROSPECTION_GIRS)
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
endif
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
# ------------------- MSVC Build Items ----------------
MSVCPROJS = gsk-4
gsk_4_FILES = $(all_sources) $(gsk_built_source_c)
Visual Studio builds: Include Vulkan sources in GSK ...but disable them for now. Configs will be added for the projects to support Vulkan-enabled builds which will then enable the builds of these sources. Extra commands and items will be needed for the GSK resources along with ensuring GSK_RENDERER_GSK being defined for the build of GDK, GDK-Win32 and GSK so that the builds of Vulkan-enabled builds can be done properly. Filter out the Vulkan sources from the 'dist hook' rules in gsk/Makefile.am as we don't want to in turn include them twice in the projects when the 'make dist' is performed on a system with Vulkan builds enabled.
2016-12-29 17:08:07 +00:00
gsk_4_EXCLUDES = gskvulkan*.c
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
gsk_4_HEADERS_DIR = $(gskincludedir)
gsk_4_HEADERS_INST = $(gskinclude_HEADERS)
gsk_4_HEADERS_EXCLUDES = dummy
Visual Studio builds: Move project files to win32/ It was suggested that the project files to be moved to win32/, so that we can have one less layer of directories we need to go down into to reach the project files.
2017-01-09 07:33:25 +00:00
include $(top_srcdir)/win32/Makefile.msvcproj
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
Visual Studio builds: Move project files to win32/ It was suggested that the project files to be moved to win32/, so that we can have one less layer of directories we need to go down into to reach the project files.
2017-01-09 07:33:25 +00:00
$(top_builddir)/win32/gsk.enum.headers: Makefile $(gsk_public_source_h)
-$(RM) $(top_builddir)/win32/gsk.enum.headers
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
for F in $(gsk_public_source_h); do \
case $$F in \
*.h) \
Visual Studio builds: Move project files to win32/ It was suggested that the project files to be moved to win32/, so that we can have one less layer of directories we need to go down into to reach the project files.
2017-01-09 07:33:25 +00:00
echo $$F' ^'>>$(top_builddir)/win32/gsk.enum.headers \
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
;; \
esac \
done
if HAVE_INTROSPECTION
# Introspection Items for MSVC
MSVC_INTROSPECT_GIRS = Gsk-4.0.gir
BASE_MSVC_GIR_CFLAGS = \
$(GSK_CFLAG_DEFINES) \
-I../.. -I../../gdk -I.../../gsk
INTROSPECTION_INTERMEDIATE_ITEMS = \
Visual Studio builds: Move project files to win32/ It was suggested that the project files to be moved to win32/, so that we can have one less layer of directories we need to go down into to reach the project files.
2017-01-09 07:33:25 +00:00
$(top_builddir)/win32/Gsk-4.0.gir.msvc.introspect \
$(top_builddir)/win32/Gsk_4_0_gir_list \
$(top_builddir)/win32/gsk.enum.headers
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
Gsk_4_0_gir_MSVC_FILES = $(introspection_files)
autotools: Update MSVC gir build script generation Now that GTK+ is built as a single DLL, and the .lib that is built is gtk-4.lib, we need to update the autotools sections in generating the NMake Makefile snippets so that we can have the correct commands and flags for building the .gir files, which will all now link to gtk-4-vsXX.dll (or so).
2016-11-03 10:00:03 +00:00
Gsk_4_0_gir_MSVC_EXPORT_PACKAGES = $(Gsk_noinst_4_0_gir_EXPORT_PACKAGES)
Gsk_4_0_gir_MSVC_INCLUDE_GIRS = $(Gsk_noinst_4_0_gir_INCLUDES)
Gsk_4_0_gir_MSVC_LIBS = gtk-4
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
Gsk_4_0_gir_MSVC_CFLAGS = $(BASE_MSVC_GIR_CFLAGS)
Gsk_4_0_gir_MSVC_SCANNERFLAGS = \
--add-include-path=. \
autotools: Update MSVC gir build script generation Now that GTK+ is built as a single DLL, and the .lib that is built is gtk-4.lib, we need to update the autotools sections in generating the NMake Makefile snippets so that we can have the correct commands and flags for building the .gir files, which will all now link to gtk-4-vsXX.dll (or so).
2016-11-03 10:00:03 +00:00
--include-uninstalled=../gdk/Gdk-4.0.gir
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
Visual Studio builds: Move project files to win32/ It was suggested that the project files to be moved to win32/, so that we can have one less layer of directories we need to go down into to reach the project files.
2017-01-09 07:33:25 +00:00
include $(top_srcdir)/win32/Makefile.msvc-introspection
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
else
INTROSPECTION_INTERMEDIATE_ITEMS =
endif
dist-hook: \
Visual Studio builds: Move project files to win32/ It was suggested that the project files to be moved to win32/, so that we can have one less layer of directories we need to go down into to reach the project files.
2017-01-09 07:33:25 +00:00
$(top_builddir)/win32/vs12/gsk-4.vcxproj \
$(top_builddir)/win32/vs12/gsk-4.vs12.headers \
$(top_builddir)/win32/gsk.enum.headers \
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
$(INTROSPECTION_INTERMEDIATE_ITEMS)
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
-include $(top_srcdir)/git.mk
Reference in New Issue Copy Permalink