Age | Commit message (Collapse) | Author | Files | Lines |
|
Newer versions of the Vala compiler have got stricter about unnecessary
(owned) transfer annotations. Folks had some unnecessary ones, which
have now been removed. This shouldn’t affect compilation with older
versions of Vala, though this is untested.
https://bugzilla.gnome.org/show_bug.cgi?id=723054
|
|
Reduce signal duplication. Inspired by the dummy backend.
|
|
The API version is included in the GIR file name, and only changes when
API is broken or removed. If new backends, such as the dummy backend,
are to have unstable APIs, having individual versions for each backend
library is necessary to allow backend API breaks without breaking the
whole of the folks API.
The API version has not been added to the VAPI file name, though it
should, because that would be a backwards-incompatible change. It can be
added when folks next breaks API compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=711544
|
|
This simplifies and standardises the build process for the installed
backend libraries (libfolks-eds.so and friends).
https://bugzilla.gnome.org/show_bug.cgi?id=711544
|
|
No need to create a new directory variable; just use lib_LTLIBRARIES
directly.
https://bugzilla.gnome.org/show_bug.cgi?id=711544
|
|
With the addition of the dummy backend, backend libraries (such as
libfolks-dummy.so) no longer necessarily have the same stability guarantees
as the core of libfolks. Consequently, they must have separate LT versions.
These versions will be incremented in-line with the core LT version, but
may also be incremented separately. They don’t affect whether libfolks will
load a given backend module (that’s predicated on the core LT current
version); merely whether client code needs to be re-linked against a given
backend library due to an ABI-incompatible change in its backend-specific
API.
https://bugzilla.gnome.org/show_bug.cgi?id=711544
|
|
Make it more obvious, and also make it non-optional.
https://bugzilla.gnome.org/show_bug.cgi?id=712274
|
|
Remembering to always append to AM_VALAFLAGS, rather than define it from
scratch, is hard and error-prone. Simpler and more consistent to define a
new variable, TARGET_VALAFLAGS, which must be manually included in every
AM_VALAFLAGS or target-specific *_VALAFLAGS declaration.
https://bugzilla.gnome.org/show_bug.cgi?id=712274
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=711544
|
|
Ensure that g-ir-scanner’s PKG_CONFIG_PATH includes the build
directory containing the generated -uninstalled.pc files for folks,
so that the backends can link against it properly for being scanned.
https://bugzilla.gnome.org/show_bug.cgi?id=708059
|
|
Copy–paste errors.
|
|
This makes the backends’ build process so much more consistent, and reduces
a huge amount of copy–paste automakery.
|
|
They were constructed, made one method call in their constructor, and then
sat there for the lifetime of the process, using a little bit of memory each,
and not doing anything else.
Instead, just add the new Backend to the BackendStore directly from the
module initialiser. This cuts out a reasonable amount of generated C, and
slightly reduces memory overheads. Yay!
|
|
The GCC warning spew which results from Vala’s non-perfect generated C
code is distracting and can mask genuine warnings from valac or GCC.
This patch adds some #pragmas in warnings.h which disable as many of these
warnings as possible. Unfortunately some of the warnings are for const
qualifier discards and passing parameters of the wrong type, which (as far
as I know) can’t be disabled.
In any case, this patch eliminates GCC warnings for several C files, which is
better than nothing.
Note that warnings.h should only be included in build targets which compile
only Vala, and don’t compile any non-generated C code. Non-generated C code
should always be compiled with all warnings enabled, to catch legitimate
errors. See the comment at the top of warnings.h.
https://bugzilla.gnome.org/show_bug.cgi?id=710869
|
|
|
|
Bug #682698 means that Vala does not null-terminate const arrays, yet it
expects them to be null terminated when returning them to g_object_get().
This results in g_object_get() walking off into arbitrary memory, and Bad
Things happen shortly afterwards.
Work around this (because it doesn’t look like the Vala bug is going to be
fixed any time soon) by manually null-terminating all const arrays (typically
linkable_properties and writeable_properties lists in backends) and modifying
code which iterates over them to ignore null entries.
https://bugzilla.gnome.org/show_bug.cgi?id=682698
|
|
Vala knows more about the types used in the code, and doesn’t emit any
GIR annotations; so g-ir-scanner is left guessing about (transfer)
annotations (amongst others).
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=705608
|
|
This reverts commit 4c06ecc26bfde7397357ef4ae7ad83a5925db43d
because it caused build failures when building folks for the first time
without a system-installed copy of the development headers.
|
|
|
|
|
|
As long as --vapi and -H/-h options are correctly passed to a target-specific
VALAFLAGS, automake will automatically add these generated files to the
maintainer-clean target.
Helps: https://bugzilla.gnome.org/show_bug.cgi?id=701099
|
|
This allows automake to parse the flags for each target and generate
appropriate rules. For example, by explicitly specifying “--vapi foo.vapi” in
foo_VALAFLAGS (not just specifying “--library foo”), dependency and clean-up
rules for foo.vapi will be generated by automake. Accordingly, this commit
also adds missing --vapi flags.
Helps: https://bugzilla.gnome.org/show_bug.cgi?id=701099
|
|
Now that git.mk has been modified to add better Vala support, these
are unnecessary.
|
|
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=703450
|
|
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=703402
|
|
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=702490
|
|
AM_CFLAGS was missing from a couple of foo_CFLAGS variables (it isn't
"inherited" automatically), so add that too.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697354
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
Notable exceptions are:
* sets of personas that are, or might be, the entire set from a backend
(possible future refinement: use a SmallSet if there aren't many)
* sets of potentially many Individuals (likewise)
* the object cache (potentially pretty large)
* debug stuff (not relevant for performance)
* the set of IM addresses being matched (we want to keep this O(1),
but it should be a GHashTable)
This speeds up tests/eds/perf by around 5%.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687161
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
[squashed in responses to review -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
libfolks.la embeds a copy of libfolks-internal.la, so every public
(or internal) symbol in libfolks-internal.la is available in
libfolks.la, even if linked with -Wl,--no-copy-dt-needed-entries.
If libfolks-internal.la defines a GObject type, then linking two copies
of it is actively harmful, because they can't both be registered with the
type system.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687161
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
This will become more important if we use C to implement fast-paths
and faster data structures.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=695381
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
GObject (and hence Vala) already knows how to memory-manage a Contact,
because it's a boxed type. Trying to do our own memory-management
anyway results in an occasional (50%?) double-free and crash.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=695719
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
Users should be able to do "make VALAFLAGS=--enable-experimental-non-null"
without overriding necessary flags like --target-glib=2.24. The variable
for use by package maintainers is AM_VALAFLAGS.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=695628
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
|
|
Automake adds (the equivalent of) -I$(top_builddir) to our CPPFLAGS
automatically, so we can #include "config.h". It does not add
-I$(top_srcdir). Many things in folks want to #include <folks/folks.h>,
so we should always have -I$(top_srcdir) so we can pick that up.
Out-of-tree builds previously either didn't work, or relied on having
installed folks headers (I'm not sure which).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=694883
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
[amended to do the same for tracker- and libsocialweb-specifics too -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|
|
Added hash_static and equal_static to AbstractFieldDetails.
Use AbstractFieldDetails hash_static and equal_static where needed.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=673918
|
|
This is a follow-up commit to ce55fa2bf2f5f8cf95532da585d835bafeeb3347.
I went through all methods in folks which yield to another async method,
and tried to work out whether the caller was safe to run multiple times
concurrently (e.g. begin a second asynchronous call to it between a previous
async call beginning and finishing).
I’ve marked all such methods as safe (or not safe) as appropriate. I
haven’t made any attempt to make the unsafe methods safe, except in one
case in backend-store.vala.
|
|
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=686673
|
|
This covers the libsocialweb backend.
Helps: https://bugzilla.gnome.org/show_bug.cgi?id=681420
|
|
The syntax is ‘``monospaced text``’ rather than ‘`monospaced text`’, which
we were consistently getting wrong. Valadoc now produces the correct markup
for monospaced text, but it doesn’t appear differently from other text at
the moment due to Valadoc not having any CSS for it. That will change soon.
Similarly, Valadoc currently produces the wrong markup for monospaced text
with the gtkdoc doclet, but that will soon be fixed.
See: https://bugzilla.gnome.org/show_bug.cgi?id=681721
|
|
• Various links fixed to point to class documentation rather than its
constructor documentation (this is a quirk of Valadoc; if using
“{@link ClassName}” inside a method of ClassName, the link will point to
ClassName’s constructor because symbols are resolved relatively and the
class’ constructor is called “ClassName”).
• Various bits of documentation expanded (mostly trivially) to shut gtk-doc
up about missing long descriptions.
• Some Vala code attributes moved around so the documentation comments are
correctly associated with the code. (This shouldn’t change the behaviour
of the attributes themselves.)
• Some trivial constructors added to classes in order to give them
documentation.
• Constructor for Utils added and deprecated immediately. Utils should
become a nested namespace on the next API break, since it will only ever
contain static methods, and thus doesn’t need to be instantiable (which
folks will make it at the moment).
|
|
This reverts commit 5b5360bff7a61ef17173cbe35cc32712ca0fc329.
|
|
This reverts commit e069bbe59dc54eb3595d8ee5c96aea4a36cff9aa.
|
|
|
|
Minor style fixes based on review of previous changes.
|
|
|
|
Helps: bgo#652637 - Don't hold locks across async calls
|
|
Added hash_static and equal_static to AbstractFieldDetails.
Use AbstractFieldDetails hash_static and equal_static where needed.
|
|
|
|
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=679020
|
|
The API outputs messages in the format accepted by Federico’s
plot-timeline.py (http://people.gnome.org/~federico/news-2006-03.html#timeline-tools)
so graphs can easily be generated by running:
strace -ttt -f -o /tmp/logfile folks-inspect
python plot-timeline.py -o graph.png /tmp/logfile
So far, the BackendStore, IndividualAggregator and Backend and PersonaStore
classes for all the backends have been annotated.
|