2020-11-21 Kjell Ahlstedt 2.64.4 2020-11-19 Kjell Ahlstedt Remove unnecessary TODO and README files 2020-11-18 Kjell Ahlstedt generate_wrap_init.pl.in: Use g_type_ensure() Call g_type_ensure(SomeClass::get_type()). Redefining the G_GNUC_CONST preprocessor macro does not have the intended effect (SomeClass::get_type() actually being called) if the package is compiled and linked with the -flto option. LTO = link time optimization https://mail.gnome.org/archives/gtkmm-list/2020-November/msg00009.html 2020-11-01 Kjell Ahlstedt Gio::File docs: Fix names of thrown exceptions and remove unnecessary TODO comments in several files. 2020-10-12 Kjell Ahlstedt glib/glibmm.h: Describe how to use glibmm with meson 2020-10-01 Kjell Ahlstedt Meson build: Fix versioning on macOS for libglibmm_generate_extra_defs 2020-09-30 Kjell Ahlstedt Meson build: Fix versioning on macOS See https://github.com/libsigcplusplus/libsigcplusplus/pull/65 2020-09-13 Kjell Ahlstedt Meson build: Add missing Glib::Value and Variant documentation The value_basictypes.h and variant_basictypes.h files, which are generated from .m4 files, were not included in the input to Doxygen. 2020-09-07 Kjell Ahlstedt Glib::BalancedTree docs: Recommend std::map or std::unordered_map 2020-08-31 Chun-wei Fan class_interface.m4: Export the generated private class As in the case of class_shared.m4, we need to do the same for class_interface.m4 as well, in order to export the items in the private headers fully. 2020-08-29 Kjell Ahlstedt gmmproc: Make h2def.py recognize more macros When parsing function declarations, remove G_DECLARE_DERIVABLE_TYPE and GDK_DECLARE_INTERNAL_TYPE. 2020-08-28 Chun-wei Fan glib/glibmm/private/*.h: Decorate the classes with GLIBMM_API This is done for completeness' sake, as we are doing for the private headers that we generate. 2020-08-28 Chun-wei Fan class_shared.m4: Decorate private class prototype ...when using _WRAP_GOBJECT with a function decoration. This will help expose the class definition in the generated private/*_p.h in the built DLLs/LIBs that is built with Visual Studio or clang-cl. 2020-07-23 Chun-wei Fan NMake Makefiles: Use Meson-style DLL and .lib naming if requested To make things more consistent and less prone to confusion, if 'USE_MESON_LIBS' is specified in the NMake command line, build the DLLs and .lib's that are named like the Meson counterparts. Binaries built with Meson+Visual Studio and the ones that are built via NMake using 'USE_MESON_LIBS' are interchangeable, provided that they are built with the same Visual Studio version. 2020-07-22 Chun-wei Fan NMake Makefiles: Fix generating [glib|gio]mm[config.h|.rc] This fixes the build process so that we won't need to generate them unnecessarily (i.e. when building from a release tarball built with autotools). Also streamline the build process that we no longer need to explicitly run the 'prep-git-build' target before building, where we generate [glib|gio]mm[config.h|.rc], and if needed, gmmproc and generate_wrap_init.pl, as part of the normal 'all' target if necessary 2020-07-14 Chun-wei Fan NMake Makefiles: Support ARM64 Windows builds This will make the NMake Makefiles capable of building ARM64 binaries of glibmm and giomm, which can be used on Windows 10 on ARM systems. 2020-07-11 Kjell Ahlstedt gmmproc: _CLASS_BOXEDTYPE, _CLASS_OPAQUE_COPYABLE: Fix move assignment Add a std::move() to avoid copying. Fixes #76 2020-06-29 Kjell Ahlstedt docs/reference/: Update for Doxygen >= 1.8.16 * docs/reference/meson.build: Doxygen 1.8.16 and later does not store tag file names in the html files. This requires changes in meson.build and in doc-install.pl (in mm-common). Otherwise references to other modules won't be updated in the html files when they are installed. * docs/reference/Doxyfile.in: Remove PERL_PATH and MSCGEN_PATH. Doxygen since version 1.8.0 does not use them. 2020-06-18 Chun-wei Fan Meson/Visual Studio builds: Include toolset version by default This makes the built DLL and .lib's contain the toolset version if the build is carried out using Visual Studio 2015 or later, unless the 'msvc14x-parallel-installable' option is set to be false during configuration. The reasoning behind this change is that there are subtle problems when, for instance, one tries to link to a Visual Studio 2015-built glibmm when building gtkmm and libxml++ with Visual Studio 2017 or 2019. This is unfortunate as Microsoft did try hard to make interoperating between binaries built with Visual Studio 2015, 2017 and 2019 as easy as possible in terms of ABI and API, but unfortunately this hits the corner cases where this compatibility does not work. As the name suggests, this attempts to make Visual Studio 2015, 2017 and 2019 builds share a single set of underlying C DLLs easier, while avoiding breakages caused by such subtle differences. 2020-06-16 Chun-wei Fan NMake Makefiles: Fix building GIO tests/examples Make sure we look for the GIO headers first in this build tree or source tree 2020-06-16 Chun-wei Fan NMake Makefiles: Clean up building tests and examples Instead of hand-written rules, just make use of what we have to generate the rules on the fly for most of the tests and examples, since the rules are more or less the same for each of the test and example programs. We only need to single-out the ones that aren't buildable under Windows and those that have multiple programs under each directory, as opposed to one example/test program per directory. Even for those directories that have multiple example programs, we can pretty easily generate the rules for them. Also remove repeated parts that were added by accident. This can shrink the NMake Makefiles by a bit. 2020-06-15 Chun-wei Fan glib/glibmm/ustring.h: Fix building on Visual Studio 2015 Commit 8b8af81f accidentally changed the macro check from '_MSC_VER' to 'MSC_VER', fix that, so that things build correctly on Visual Studio 2015 2020-06-12 Chun-wei Fan Update README.win32 Let people know that it is recommended (and even required at some points) to use the same Visual Studio version for building glibmm and dependent software, even for Visual Studio 2015, 2017 and 2019. 2020-06-12 Chun-wei Fan NMake Makefiles: Distinguish between MSVC 2015, 2017 and 2019 It was found that we cannot rely on the fact that Visual Studio 2015~2019 tried very hard to be binary compatible, as there are corner cases when linking against glibmm built with Visual Studio 2015 with builds done by Visual Studio 2017 and 2019 where the code will fail to link and the DLLs are therefore not ABI-compatible. Note that the libsigc++ DLLs, however, are ABI compatible between these 3 Visual Studio versions. As a result, for the DLL and LIB names, use 'vc140' for Visual Studio 2015 builds, 'vc141' for Visual Studio 2017 builds and 'vc142' for Visual Studio 2019 builds, according to the toolset versions as defined by Microsoft. For people that may have previously built glibmm with Visual Studio 2017 or 2019, which had 'vc140' in the built .lib and DLL, an NMake option 'USE_COMPAT_LIBS' is added to make building such binaries with 'vc140' easier, if needed. 2020-06-03 Daniel Boles propertyproxy_base: Fix using notify w/o prop name GLib has now specified that if you want to connect to a signal without a detail argument, you omit the `::`. So, glibmm users previously connecting to `notify::` to listen for changes to all properties broke. Fix that by only passing `notify` i.e. no superfluous `::` in that case. Close https://gitlab.gnome.org/GNOME/glibmm/-/issues/74 Close https://gitlab.gnome.org/GNOME/glibmm/-/merge_requests/35 2020-06-02 Daniel Boles ustring: Silence warning if MSC_VER is undefined/0 2020-05-21 Kjell Ahlstedt tools/defs_gen/*.py: Specify that this is python3 code Specify #!/usr/bin/env python3, making it unnecessary to have a python command which is a link to python3. In h2def.py, use the built-in set() instead of Set() from the sets module. 2020-04-11 Chun-wei Fan tools/m4/compare.m4: Allow decorating comparison operators This allows one to pass in deocrations for the comparison operators so that those decorations may be defined as compiler directives to export symbols in a more fine-grained manner. 2020-04-08 Kjell Ahlstedt tools/gmmproc.in: Add a comment 2020-04-05 Kjell Ahlstedt Meson build: Set default value of the 'warnings' option to 'min' * meson.build: Use dist-warnings when a tarball is tested by 'ninja dist' or 'meson dist'. Check if generate-binding.py exists, if not maintainer-mode. Add a better error message if mm-common-get is required but not found. * meson_options.txt: Set default value of the 'warnings' to 'min'. Add 'dist-warnings' with default value 'fatal'. 2020-04-04 Chun-wei Fan Bump version We need to update the version so that we can be able to check whether we have enough support in gmmproc to be ready to use __declspec(dllexport) instead of gendef.exe to export symbols for modules that build on top of the glibmm-2.4 branch, as they may well depend on older stable glibmm-2.4 versions that do not have such support. 2020-04-04 Chun-wei Fan gio/src/*.hg: Mark all _WRAP_ENUM() with decl_prefix As per Kjell's suggestions, make things more future-proof by marking all _WRAP_ENUM()'s with 'decl_prefix GIOMM_API'. 2020-04-04 Chun-wei Fan glib/src/*.hg: Mark all _WRAP_ENUM() with decl_prefix As per Kjell's suggestions, make things more future-proof by marking all _WRAP_ENUM()'s with 'decl_prefix GLIBMM_API'. 2020-04-04 Chun-wei Fan gio/src: Apply `decl_prefix GIOMM_API` to _WRAP_ENUM This way, we can ensure that the headers generated with gmmproc marks the template<> classes with GIOMM_API, so that we can export them in Visual Studio builds. Note that for those _WRAP_ENUM calls marked with NO_GTYPE, there is no need to add 'decl_prefix ...'. 2020-04-04 Chun-wei Fan glib/src: Apply `decl_prefix GLIBMM_API` to _WRAP_ENUM This way, we can ensure that the headers generated with gmmproc marks the template<> classes with GLIBMM_API, so that we can export them in Visual Studio builds. Note that for those _WRAP_ENUM calls marked with NO_GTYPE, there is no need to add 'decl_prefix ...'. 2020-04-04 Chun-wei Fan tools/[gerror|enum].m4: Make template<> classes exportable Allow to apply the decl_prefix argument onto the template<> classes that we generate for the _WRAP_GERROR and _WRAP_ENUM directives in the various *.hg files, if specified.