| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
The default value will be changed in future Meson releases.
Don't use deprecated python3.path() and execute(..., gui_app: ...).
|
|
|
|
| |
Fixes #89
|
|
|
|
|
|
|
|
|
|
|
| |
* meson.build:
* docs/reference/meson.build:
* gio/giomm/meson.build:
* glib/glibmm/meson.build:
Call add_dist_script() in a subproject, if meson.version() >= 0.58.0.
* tools/build_scripts/handle-built-files.py:
Use MESON_PROJECT_DIST_ROOT if it exists, else MESON_DIST_ROOT.
It exists if meson.version() >= 0.58.0.
|
|
|
|
|
|
|
| |
It shall not be possible to find a glibmm header file
with #include <xxx.h> instead of #include <glibmm/xxx.h>.
Not fully fixed until https://github.com/mesonbuild/meson/issues/8562
has been fixed.
|
|
|
|
| |
glib and sigc++ can be subprojects of glibmm.
|
|
|
|
|
|
|
| |
The paths to the source code in untracked/ shall be relative to the
meson.build file, when library files are built from a tarball.
With absolute paths Meson may generate too long file names.
See gtkmm!61
|
|
|
|
| |
See https://github.com/libsigcplusplus/libsigcplusplus/pull/65
|
|
|
|
|
| |
The value_basictypes.h and variant_basictypes.h files, which are generated
from .m4 files, were not included in the input to Doxygen.
|
|
|
|
| |
Use std::map or std::unordered_map instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the built DLL and .lib's contain the toolset version if the build is
carried out using Visual Studio 2017 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 2017-built glibmm when building
gtkmm and libxml++ with Visual Studio 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 2017 and 2019
builds share a single set of underlying C DLLs easier, while avoiding breakages
caused by such subtle differences.
|
|
|
|
|
|
|
|
|
|
|
| |
Clean up the build files a bit and update the glibmmconfig.h.[in|meson] so that
we use __declspec(dllexport) when GLIBMM_BUILD is defined (i.e. during the
build of glibmm) on Visual Studio.
Also, for the meson builds, disable warnings 4251 and 4275 as they all relate
to building DLLs regarding symbol export, which is harmless as we know clearly
that we are indeed building DLLs in our case, and we have already set
GLIBMM_API appropriately
|
|
|
|
|
| |
wrap_init.cc shall be rebuilt when generate_wrap_init.pl has been rebuilt.
Generated .h and .cc files shall be rebuilt when gmmproc has been rebuilt.
|
|
|
|
|
|
|
|
| |
Let builds from release tarballs and GIT checkouts build the glibmm-int
static library, and link the final .so/.dll from the objects that form
glibmm-int static .lib. By doing so we can build glibmm with the import
libraries for Visual Studio builds with gendef, as well as linking in
the version resource for all Windows builds.
|
|
glibmm can be built with either Autotools or Meson.
See MR !27
|