gcontenttype.c was split into gcontenttype.c and gcontenttype-win32.c
in commit 32192ee9 ("Split gcontenttype.c"), so we don't want to include
gcontenttype.c in the Visual C++ build as it is no longer a source file
meant for Windows.
Thanks to Thomas H.P. Anderson for pointing this out.
The bash-completion code nowadays expects completion files to
be installed in /usr/share/bash-completion/completions, and
expects them to be named like the command they are completing
for.
https://bugzilla.gnome.org/show_bug.cgi?id=677782
The "-framework" linker flag takes a second word as a parameter. If
they are passed separated with whitespace, some flag-handling routines
may not know to keep the two words together as a single unit. Use
-Wl,, to pass multiple words without embedded whitespace.
https://bugzilla.gnome.org/show_bug.cgi?id=566994
Commit f084b60377 incorrectly set
DIST_SUBDIRS for the toplevel Makefile.am. In general actually we
don't need to set it, because modern automake automatically sets
it by looking at conditionals for SUBDIRS.
Tested-by: Rico Tzschichholz <ricotz@t-online.de>
https://bugzilla.gnome.org/show_bug.cgi?id=667806
gdbus-daemon-generated.[ch] failed to build because it depended
on gdbus-2.0/codegen/gdbus-codegen which was build during the SUBDIRS part
of the build, however SUBDIRS are done *after* processing BUILT_SOURCES,
and these files are in BUILT_SOURCES.
The fix is simple, instead of running the gdbus-codegen code we
run the gdbus-codegen.in code, which works fine for uninstalled execution.
I also removed Makefile from the dependencies to avoid rebuilding the file
in tarballs, as Makefiles are written at configure time. We should be able to
ship the prebuilt files in the tarballs.
When running uninstalled
This is mostly complete, sans support for activation. However, its
not as picky as the libdbus implementation in terms like validation
and limits checking, nor is it as tested.
Its can be useful to test gdbus if dbus-daemon is not availible, but
its main reason for existance is to implement a default session bus
on win32 so that e.g. GApplication is guaranteed to work.
Move g_pollable_source_new() here from gpollableinputstream.c, add
g_pollable_source_new_full(), and add some new methods to do either
blocking or nonblocking reads depending on a boolean argument.
https://bugzilla.gnome.org/show_bug.cgi?id=673997
This patch solves two problems:
First, it allows builders to optionally cut the circular dependency
between dbus and glib by disabling the modular tests (just like how
the tests can be disabled in dbus).
Second, the tests are entirely pointless to build if cross-compiling.
It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree. This would allow us to
run the tests constantly, not just when glib is built.
https://bugzilla.gnome.org/show_bug.cgi?id=667806
On some systems gelf.h may not be stored under the top level include
directory in which case we need to add the correct include paths in
cflags by using pkg-config(1).
When building with MinGW/MSYS with srcdir != builddir the build fails:
- to locate the generated .def files
- creating libglib-gdb.py
- creating libgobject-gdb.py
Solved this by explicitly instructing these files to be generated
in $(builddir)/...
https://bugzilla.gnome.org/show_bug.cgi?id=653167
Helper scripts in C can be problematic for cross compiling: the compiler
produces executables for the target platform, which the host is usually
unable to run.
https://bugzilla.gnome.org/show_bug.cgi?id=669224
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
This lets you poke at resources in elf files and
standalone resource bundles. So far, only listing
and extracting resources is supported. The support
for elf files requires libelf.
GResource is a bundle of files combined into a single binary blog.
The API lets you access the files the resource contains by
using resource paths. You can also register resources with a
global list and access these globally in a merged resource namespace.
The normal way this is used is to link in the resources into your
application/library and have it be automatically registred.
Resources are compiled from an xml description using
glib-compile-resources.
This interfaceifies the extra functions that were on GDBusActionGroup
for dealing with platform data.
The two main benefits of doing this:
- no longer have to do a silly song and dance in GApplication to avoid
calling GDBusActionGroup API from non-dbus-aware code
- the interface can be reused by the action group exporter to avoid
ugly and unbindable hook callbacks
https://bugzilla.gnome.org/show_bug.cgi?id=665737
Clean up the docs for GApplication and related classes.
I'm no longer writing documentation for the structure type of classes
and interfaces. See https://bugzilla.gnome.org/show_bug.cgi?id=665926
for discussin on the correct way forward on this point.
Also: stop putting gtk-doc comments in installed headers.
This is an interface to represent GSimpleActionGroup-like objects (ie:
those GActionGroups that operate by containing a number of named GAction
instances).
Add GNetworkMonitor and its associated extension point, provide a base
implementation that always claims the network is available, and a
netlink-based implementation built on top of that that actually tracks
the network state.
https://bugzilla.gnome.org/show_bug.cgi?id=620932
