1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
Building glibmm on Win32
===========================
Currently, both the mingw (native win32) gcc compiler and MS Visual
Studio 2017 and later are supported. glibmm can be built with
mingw32-gcc using the gnu autotools (automake, autoconf, libtool).
As explicitly stated in the gtk+ for win32 distribution
(http://www.gimp.org/win32/), the gcc compiler provided by the cygwin
distribution should not be used to build glib/glibmm libraries and/or
applications (see the README.win32 that comes with the gtk+ DLLs).
This MIGHT cause conflicts between the cygwin and msvcrt runtime
environments.
1. Mingw
The mingw distribution which has been tested with this release is the
following :
* MinGW-4.1 as the base distribution.
The bare mingw distribution does not provide the necessary tools (sh, perl, m4
, autoconf, automake, ..) to run the provided configure script "as is". One
(currently non supported) solution is to use mingw in conjunction with msys,
which is readily available on the mingw website (http://www.mingw.org/).
The preferred method is to combine the cygwin distribution (for the unix tools
that were mentioned above) with mingw by making sure that the mingw
tools (gcc, ld, dlltool, ..) are called first.
First, make sure that you have working distribution of the native port
of both libsigc++-3.0.x and glib-2.0 on win32 (see
http://www.gimp.org/win32). If you can't compile a simple glib example
using gcc and `pkg-config --cflags --libs`, you should not even think
about trying to compile glibmm, let alone using precompiled libglibmm
DLLs to port your glibmm application !
The configure script can then be called using (as an example) the
following options
./configure --prefix=/target --build=i386-pc-mingw32 --disable-static
then
make
make check
make install
2. MS Visual Studio 2017
In a Visual Studio command prompt, navigate to the MSVC_NMake directory.
Run 'nmake /f Makefile.vc CFG=[release|debug]' to build the glibmm and
giomm DLLs, along with their example programs. If a prefix other than
$(srcroot)\..\vs15\$(Platform) is desired, pass in PREFIX=$(your_prefix)
in the NMake command line. In order to build the giomm settings example
program, the glib-compile-schemas needs to reside in $(PREFIX)\bin, or
it must be specified via passing in GLIB_COMPILE_SCHEMAS. If using C++
dependencies that are built with Meson, specify USE_MESON_LIBS=1 in your
NMake command line.
Note that $(VSVER) refers to 15 for Visual Studio 2017 and 16 for Visual
Studio 2019. Note that it is recommended and possibly required to build
glibmm and anything that depends on glibmm with the same Visual Studio
version, even for Visual Studio 2017 and 2019 which Microsoft tried
very hard to make the binaries API and ABI compatible between these versions.
The build now creates DLLs and .lib's based on the toolset version (i.e.
'vc141' for Visual Studio 2017 builds and 'vc142' for Visual Studio 2019
builds instead of vc$(VSVER)0 as before, to be consistent across the board).
Since it might be desired to use the old naming scheme, a 'USE_COMPAT_LIBS=1'
may be used for such situations, such as when re-building dependent code is
inconvenient. For the Meson builds, pass in the option
'-Dmsvc14x-parallel-installable=false' to the Meson configure command line
to avoid having the toolset version in the final DLL and .lib filenames;
again, this is only recommended if it is inconvenient to re-build the
dependent code.
A 'tests' target will build the test programs for glibmm and giomm, an
'install' target is provided to copy the built DLLs and LIBs, along with
with the public headers to appropriate subdirs of $(PREFIX). A 'clean'
target is also provided to remove all the built files.
The NMake Makefiles now support building the glibmm libraries directly from a GIT checkout
with a few manual steps required, namely to:
-Ensure that you have a copy of Cygwin or MSYS/MSYS64 installed, including
m4.exe and sh.exe. You should also have a PERL for Windows installation
as well, and your PATH should contain the paths to your PERL interpreter
and the bin\ directory of your Cygwin or MSYS/MSYS64 installation, and
it is recommended that these paths are towards the end of your PATH. You need
to install the XML::Parser PERL module as well, which requires libexpat.
-Make a new copy of the entire source tree to some location, where the build
is to be done; then in $(srcroot)\MSVC_NMake run
nmake /f Makefile.vc CFG=[release|debug], which will first copy and generate
the following files with the proper info (this step will also be run if the following
files are not present in the unpacked source tarball):
--$(srcroot)\MSVC_NMake\glibmm\glibmmconfig.h
--$(srcroot)\MSVC_NMake\giomm\giommconfig.h
--$(srcroot)\MSVC_NMake\glibmm\glibmm.rc
--$(srcroot)\MSVC_NMake\giomm\giomm.rc
--$(srcroot)\tools\gmmproc
--$(srcroot)\tools\generate_wrap_init.pl
For giommconfig.h, it is recommended to keep GIOMM_STATIC_LIB and GIOMM_DISABLE_DEPRECATED
undefined unless you know what you are doing (remember, the NMake Makefiles only support DLL
builds out-of-the-box). For builds from the release tarballs, running
nmake /f Makefile.vc CFG=[release|debug] gen-perl-scripts-real will also generate
$(srcroot)\tools\gmmproc and $(srcroot)\tools\generate_wrap_init.pl for you.
Note that to generate any of the above 6 files, a PERL installation is also required.
3. Glibmm methods and signals not available on win32
All glibmm methods and signals are available on win32.
|
