gio's glib-mkenums call needs to get gnetworking.h out of $(builddir),
not $(srcdir). Fix/simplify it by using $(filter) on $^ and letting
make find everything.
Also add -Wno-portability to AM_INIT_AUTOMAKE in configure.ac, so that
it doesn't warn about this (or about the gmake-specific features we
were already using in gio/tests/)
https://bugzilla.gnome.org/show_bug.cgi?id=691866
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
Since Windows builds by Visual C++ do not make use of autotools during
its build process, we need to dist a pre-configured
gio/gnetworking.h(.win32) for such builds.
The vs9/vs10 (and therefore vs11) property sheets are updated as well
https://bugzilla.gnome.org/show_bug.cgi?id=690163
Install a public "gnetworking.h" header that can be used to include
the relevant OS-dependent networking headers. This does not really
abstract away unix-vs-windows however; error codes, in particular,
are incompatible.
gnetworkingprivate.h now contains just a few internal URI-related
functions
Also add a g_networking_init() function to gnetworking.h, which can be
used to explicitly initialize OS-level networking, rather than having
that happen as a side-effect of registering GInetAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
Written by Dmitry Matveev as part of GSoC 2011:
http://netbsd-soc.sourceforge.net/projects/kqueue4gio/
This brings native file monitoring support on systems supporting kqueue(3)
(all BSDs) and remove the need to rely on the unmaintained gamin software.
The backend adds GKqueueDirectoryMonitor and GKqueueFileMonitor.
Some parts rewritten by myself (to prevent needing a configuration file).
Helpful inputs from Colin Walters and Simon McVittie.
https://bugzilla.gnome.org/show_bug.cgi?id=679793
Even private functions that are actually called across compilation
units should have prototypes. For g_dbus_action_group_sync(), create
one in gdbusactiongroup-private.h
https://bugzilla.gnome.org/show_bug.cgi?id=687385
GTask is a replacement for GSimpleAsyncResult and GIOScheduler, that
also allows for making cancellable wrappers around non-cancellable
functions (as in GThreadedResolver).
https://bugzilla.gnome.org/show_bug.cgi?id=661767
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.
