GitLab

and set active items in the combo boxes, so something is shown.

Doxygen in a main project shall not be called before tag files have been
created or updated in subprojects.

* meson.build: If mm-common-get is not found in maintainer-mode
with 'required: false', try with 'required: true'.
Don't try to use tag_file, if documentation is not built.
* docs/reference/meson.build: Don't use variables from modules
that don't define doxytagfile. These are subprojects that don't build
their documentation.

Like the last NMake Makefiles commit, drop the ignores for warnings C4251,
C4273 and C4275 as the code is now free of items that trigger those warnings.

Drop the ignores for warnings C4251, C4273 and C4275 from the warnings that we
want to ignore, as the code is now free of items that trigger those warnings.

Also, reorganize the compiler flags for gtkmm-demo as it is actually the /GL
flag that triggered the internal compiler error when it is used with /EHsc on
32-bit Visual Studio 2015 and 2017 builds.  Likewise, disable the /LTCG linker
option when building Visual Studio 2015 and 2017 32-bit builds.

This class contains a std::vector<GType> member, so don't export this class as
a whole but export its methods individually.

This will eliminate warning C4251 and avoid having the built code depend on a
specific STL and compiler version

The decoration macro should be GTKMM_API, not GDKMM_API

Call add_dist_script() in a subproject, if meson.version() >= 0.58.0.

treeiter—Delete TreeValueProxy copy-assign/Avoid warning

See merge request !63

The user-provided, unimplemented operator=(TreeValueProxy const&)
existed to prevent the class being copied, but since a long time C++
provides a better way to do that: declaring the operator as deleted.

Doing this also avoids warnings about the implicitly declared default
copy constructor, which is deprecated due to the previously user-given
operator=, and since the latter is now deleted the warnings are avoided.

#94

gtk, gdk-pixbuf, epoxy, atkmm, cairomm, pangomm and glibmm can be
subprojects of gtkmm.
It's not guaranteed that gtk3 can be a subproject. See gtk#3775

This will fix warnings when building items using gdkmm and gtkmm with
MinGW/GCC.

Fixes: #90


(cherry picked from commit 86685b60)

Fixes:
Fatal error: can't create
gdk/gdkmm/libgdkmm-3.0.so.1.1.0.p/_buildarea1_master-wr_build_Userspace_auto-usrmerge_standalone_usrmerge_next_210222_lxbuilds_Har12345_platform_up_intel-x86-64-standard-glibc-std_wrlinux_build_tmp-glibc_work_corei7-64-wrs-linux_gtkmm3_3.24.3-r0_gtkmm-3.24.3_untracked_gdk_gdkmm_timecoord.cc.o: File name too long
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>

treepath.hg: Export comparison operators (gtkmm-3-24 branch)

See merge request !58

The 'GTKMM_API' decoration was missed from the '_WRAP_COMPARE' item,
making the code fail to link for Inkscape on Windows.  Add the needed
decoration to fix this.

Fixes issue #88.

This way, we can make gtkmm's codegen m4 scripts available to other packages
that uses them to generate sources

and add links to gdk/gdkkeysyms.h. Fixes #6

See libsigcplusplus, pull request 65

* docs/reference/README: Removed
* meson.build: Exclude some git-tracked files from generated
tarballs. Works as intended only with a new enough dist-build-scripts.py
file from mm-common-get.

gtk_actionable_get_action_target_value() does not give the caller a ref.
get_action_target_value_vfunc_callback() shall store a copy of the
returned value. It shall not give the caller a ref.

We ought to pass in the DLL filenames with the '.dll' extension, not just the
.lib filenames.

This way, we can fix gtksourceviewmm builds on Visual Studio as well, when
gtkmm was not built with gendef.exe

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.

Make sure that we do not needlessly re-generate [gdk|gtk]mm[config.h|.rc], and
ensure when they are generated, they will always contain the needed version
info in them.

Also streamline the process so that it is no longer necessary to run the
'prep-git-build' target; instead, this file generating process is carried out
when necessary when running the 'all' target.

We should also look in $(PREFIX)\include\harfbuzz and $(PREFIX)\include for
HarfBuzz (which the Pango headers may include) and Cairo (and libepoxy)
respectively, since these are likely locations where the headers are
located.

This will make the NMake Makefiles capable of building ARM64 binaries of gdkmm
and gtkmm, which can be used on Windows 10 on ARM systems.

We should also account for Visual Studio 2015 when we use 'USE_MESON_LIBS' with
'USE_COMPAT_LIBS' as well...

Note that it is possible to build with Visual Studio with Meson, on the
condition that the -mm dependencies are built with Meson as well, since we need
their pkg-config files.

Also note that the same compiler version should be used to build gtkmm and the
-mm dependencies, even for Visual Studio 2015, 2017 and 2019.

As the Meson build files for Visual Studio apply the toolset version in the
.lib filenames by default, apply the toolset version in the Meson-built -mm
.lib files that we link in, just as we did when we we link in the -mm .lib
files that was built with NMake, by default.

The option 'USE_COMPAT_LIBS' will also mean that we will use the former
behavior when we link in the Meson-built -mm .lib's, just as we did when we
link in the NMake-built -mm .lib's.