For building the introspection dumper program on Visual Studio, leave out
the G_LOG_DOMAIN as g-ir-scanner does not like it when it constructs the
compiler command line for Visual Studio.
Also ensure that we are looking for the freshly-built libraries by looking
for the .lib's from the output directories of the Visual Studio project files.
This is for adding a EGL-based renderer which is done via the ANGLE
project, which translate EGL calls to Direct3D 9/11. This is done as a
possible solution to issue #105, especially for cases where the needed
full GL extensions to map OpenGL to Direc3D is unavailable or
unreliable, or when the OpenGL implementation from the graphics drivers
are problematic.
To enable this, do the following:
-Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are
available. A sufficiently-recent ANGLE is needed for things to
work correctly--note that the copy of ANGLE that is included in
qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause
license. Note also that Visual Studio 2013 or later is required to
build ANGLE from QT-5.10.1, but the 2013-built ANGLE DLLs can work
without without problems for GTK+ that is built with Visual Studio
2008 or later.
-Build libepoxy on Windows with EGL support enabled.
-Define GDK_WIN32_ENABLE_EGL when building gdk-win32.lib when building
with Visual Studio, or pass in --enable-win32-gles during configure
when building with MinGW/mingw-w64.
-Prior to running GTK+ programs, the GDK_GL envvar needs to contain
gles.
Known issues:
-Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed
extensions, notably GL_OES_vertex_array_object, but its ES 3 support is
sufficient.
-There is no autodetection or fallback mechanism to enable using
EGL/Angle automatically yet. There is no plans to do this in this
commit.
Thanks to LRN for pointing out that we should #include
"win32/gdkwin32.h" instead of #include "gdkwin32.h" for gdkgl.c. LRN
also did the autotools portion of this patch.
Further notes about the autotools --enable-win32-gles option, fom LRN:
This adds --enable-win32-gles option, which enables the
code for GLES renderer. This commit also adds tests for WGL and
EGL in epoxy. The absence of WGL is highly unlikely (it's enabled
by default), but checking for EGL when GLES is enabled is necessary,
as EGL is disabled in Windows builds of epoxy by default.
This is the updates to the Visual Studio 2008 projects to generate
gtk/gtktypefuncs.c using the preprocessor and the gentypefuncs.py that
was adapted from master.
Unfortunately we could not clean up the projects as we did for the 201x
ones due to the differences in project file format.
Combine repetitive parts, and unify using $(PythonDir) for all builds,
which the paths set in the property sheets are now based on the Visual
Studio version and platform combination.
Not that it will make a difference, but to be consistent with the
autotools builds. Include gtkx.h instead of gtk.h when we generate the
source to feed to the preprocessor.
We now need to generate gtktypefuncs.c by ourselves, so modify the
gentypefuncs.py script from master, and add a custom build step in the
projects to generate gtktypefuncs.c. The custom build step for the 2008
projects will be added later.
Since the Cairo build files for Visual Studio does not really generate
the pkg-config files for us, and we stopped making makeshift ones in
gobject-introspection, stop making the .pc files we generate here refer
to the Cairo .pc's, and instead make them link directly to
cairo-gobject.lib and cairo.lib.
Ensure that the /DYNAMICBASE linker option (which is actually the
default) is enabled for all of our Visual Studio project builds, as the
gtk3-demo projects inadvertly disabled it.
Also, for x64 builds on MSVC 2012 or later, enable /HIGHENTROPYVA to
enhance the security of our binaries as well.
Pointed out by Ignacio Casal Quinteiro.
This is so that it is easier for one building GTK+ with Visual Studio to
build the introspection files as well in one shot. Note that this is
not built by default, so one needs to select the gtk3-introspect
explicitly to build (and clean up) the introspection files.
For this to work, one needs to ensure the following:
-A complete build of GObject-Introspection in $(GlibEtcInstallRoot),
that is built with the same installation of the Python interpretor that
is used here (see PythonDir and PythonDirX64 in
gtk3-version-paths.[vsprops|props]).
-Introspection files for ATK, GDK-Pixbuf and Pango, also in their proper
locations under $(GlibEtcInstallRoot), which should be built with the
same G-I installation.
The build/win32/detectenv-msvc.mak needs to be updated for Visual Studio
2017, and we ought to add quotes to surround the copy destination path
for the introspection files, so that we do not bail out in the copy
process (cmd.exe's copy command does not like '+' in them that are not
quoted).
This is to make this more in-line with what is in the G-I projects, so
that we could use this to build the introspection files for GTK+-3.22.x
directly from the project files. This is intended to follow the MSVC
versions used to build the official CPython Windows binaries, i.e.:
-3.3.x, 3.4.x: for MSVC 2010, 2012, 2013, which is built with 2010
-3.5.x, 3.6.x: for 2015 and 2017, which is built with 2015.
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues.
Fix this by:
-Doing what we did before on Python 2.x
-Opening the file with encoding='utf-8' on Python 3.x
Update the autotools scripts so that we can support Visual Studio 2017
by copying the 2010 projects and updating items as needed to obtain
the 2017 projects.
Note that since the toolset version string changed for Visual Studio
2017, so allow the use of a custom toolset version string, otherwise
just generate the toolset version string as we did before.
Also, note that Visual Studio 2017 aims to be compatible with 2015
on the CRT level, so there should not be any problems using 2017-compiled
binaries with 2015-compiled ones.
After building GDK with broadway, we need to copy the GDK DLL from
[Release|Debug]_Broadway\bin to [Release|Debug]\bin, so that the
introspection builds can be done normally with CFG=[Release|Debug]. As we
renamed the projects, we needed to update the property sheets that does
the copying, which was accidently missed. Fix that.
We want to look for the gdk-pixbuf-2.0 package, and we should leave a space
between -ldwmapi and -lzlib1 when we enable Broadway.
Also copy the generated gdk-3.0.pc and gtk+-3.0.pc as gdk-win32-3.0.pc and
gtk+-win32-3.0.pc respectively, to be in-line with the autotools builds.
Make the Makefile.am targets for generating the Visual Studio projects re-generate the
project files and the header listings whenever the Makefile.am's that include
build/Makefile.msvcproj changes, so that whenever a source/header is added, they will
be reflected in the projects and in the property sheets that are used to copy the
headers.
Also ensure that these are applied to the vs11, vs12 and vs14 projects when this
happens, as they are copied and processed from the Visual Studio 2010 projects.
Split out the part where we generate/update the caches for the GSchemas
and the icons, so that it is easier to ensure that things continue to
function correctly when we have GlibEtcInstallRoot != CopyDir.
Consolidate the .lib's that we need to link to for GDK and GTK+ into the
property sheets, and also link to setupapi.lib as that is needed by
the port to the new GdkMonitor API.
Generate .pc files for the package, so that it would be easier for
building introspection for packages that depend on GTK+. Also split
PythonPath into PythonPath and PythonPathX64 to facilitate the build of
introspection files, which need to have Python that is built with the
same ac=rchitecture where GTK+ is built.
Clean up the formatting and spacing a bit.
This first adds a common autotools module that can be included by
the Makefile.am's to generate the file lists and the g-ir-scanner/
g-ir-compiler command lines to build the introspection files.
The autotools files for gdk/ and gtk/ are then updated to generate
the full file lists needed to build the introspection files, with
the full command lines for g-ir-scanner and g-ir-compiler as NMake
Makefile modules that can be used to build the introspection files
for Visual Studio builds.
https://bugzilla.gnome.org/show_bug.cgi?id=765195
We are actually not using the crypt() in GDK-Broadway for quite a while,
so the code implementation for MSVC is actually not used. So, it's time
to get rid of this.
Search also for the headers in include/gio-win32-2.0, as gio.h will
include those headers at some point, and arrange the include paths in a
dependency hierarchy style, top-to-down.
On Visual Studio, unlike MinGW, manifest files are embedded via
including the manifest file as a resource file in the projects, not
via the .rc file. This means that the line in the .rc file that
specifies the manifest file would cause trouble, so that line gets
removed when the full gtk3-win32.rc is generated on Visual Studio builds,
otherwise 2010+ Visual Studio will complain when compiling the .rc file.
Also, the inclusion of winuser.h will cause warnings during the
compilation of the .rc file.
Fix this by isolating the Win32 resource portions of gtk-win32.rc.in to
gtk-win32.rc.body.in and:
-On MinGW, construct the full gtk-win32.rc by doing the winver.h and
winuser.h inclusion first, then append the contents of gtk-win32.rc.body,
and then appending the line to embed the manifest file.
-On Visual Studio, simply copy the gtk-win32.rc.body to gtk-win32.rc,
and generate the full libgtk3.manifest file.
https://bugzilla.gnome.org/show_bug.cgi?id=762311
Build the gtk-update-icon-cache, gtk-builder-tool and gtk-query-settings
tools and run gtk-update-icon-cache as part of the post-build
"installation" process.
Pointed out (and reminded) by Paolo Borelli in bug 759436 that we should
build, "install" and run gtk-update-icon-cache in the MSVC builds as well.
glib-compile-resources have been updated to ensure that the symbols
generated are referred to, so that they will not be optimized out by the
linker in release builds. We can change from /opt:noref to /opt:ref,
which should improve optimization a bit.
This partially reverts de16a4e.
As we now ensure that items using GResources and GConstructors are always
referenced so that the linker does not optimize them out in a default
Release build, we no longer need to enforce the use of /LTCG, so
/LTCG:incremental will work as well.
MSVC 2015 changed its default link-time code generation setting to
/LTCG:incremental, which causes problems if /opt:noref is to be used,
meaning that some code will be optimized out by the linker.
Avoid this situtation here by enforcing the use of /LTCG for MSVC 2010+
builds.
Use $(GlibEtcInstallRoot) when invoking glib-compile-schemas, as CopyDir
is not GlibInstallRoot for GTK+ (due to quoting issues), meaning that the
glib-compile-schemas tool may not be found in certain cases.
Issue pointed out by Ignacio Casal Quinteiro.
Update the notes that this is also used for Visual Studio 2015 support,
and correct the MSVC_VER_LONG for MSVC 2015, which is 14, not 2015.
Also add a note that this can be used for other projects that have
Visual Studio build support.
The recent changes to build/win32/vs9|10/Makefile.am fixed 'make distclean'
but broke 'make -jN dist', so fix that by listing the *.headers and using
that list as a dependency and to remove those files in one single command
right after we generate the gtk-install.vsprops template, so that we don't
have to worry about them in 'make distclean'.
This updates the Visual Studio Project GUIDs so that they don't repeat with
the GTK+-2.24.x ones, as the 3.x projects can be used with the 2.24.x in a
all-in-one solution file (such as when one wants to use a complete GTK+2
and GTK+3 stack when porting Windows applications from GTK+2 to GTK+3), and
each project in a solution file is expected to have an unique GUID.
"Add" Visual Studio 2015 projects by what we did before: Copy the Visual
Studio 2010 project files and replace the items in there as needed, as
the formats of the 2010 and 2015 projects are largely the same.
We need to rename the projects so that when these projects are added
into an all-in-one solution file that will build the GTK+ 2/3 stack,
the names of the projects will not collide with the GTK+-2.x ones,
especially as GTK+-2.x and GTK+-3.x are done to co-exist on the same
system. This is due to the case that the MSVC projects are directly
carried over from the GTK+-2.x ones and was then updated for 3.x.
We still need to update the GUIDs of the projects, so that they won't
conflict with the GTK+-2.x ones.
