summaryrefslogtreecommitdiff
path: root/backends/libsocialweb
AgeCommit message (Collapse)AuthorFilesLines
2014-01-29backends: Fix calls to ImDetails.normalise_im_address()Philip Withnall1-3/+2
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
2013-12-09backends: Add [freeze|thaw]_notify() calls to [un]prepare() in backendsPhilip Withnall1-0/+5
Reduce signal duplication. Inspired by the dummy backend.
2013-12-09build: Allow backend libraries to have individual API versionsPhilip Withnall2-31/+3
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
2013-12-09build: Factor common backends/*/lib makefilery into backend-library.mkPhilip Withnall1-113/+13
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
2013-12-09build: Minor build simplificationPhilip Withnall1-2/+1
No need to create a new directory variable; just use lib_LTLIBRARIES directly. https://bugzilla.gnome.org/show_bug.cgi?id=711544
2013-12-09build: Allow backend libraries to have separate LT versions from libfolks.soPhilip Withnall1-1/+1
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
2013-11-27build: Move backend.mk inclusions to the top of the filesPhilip Withnall1-1/+1
Make it more obvious, and also make it non-optional. https://bugzilla.gnome.org/show_bug.cgi?id=712274
2013-11-27build: Rename AM_VALAFLAGS to TARGET_VALAFLAGS in configure.acPhilip Withnall1-0/+1
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
2013-11-08build: Build backend libraries before the backend modules themselvesPhilip Withnall1-1/+1
https://bugzilla.gnome.org/show_bug.cgi?id=711544
2013-10-29build: Fix PKG_CONFIG_PATH for calls to g-ir-scannerPhilip Withnall1-0/+4
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
2013-10-28backends: Fix paths in *-uninstalled.pc.in pkg-config filesPhilip Withnall1-1/+1
Copy–paste errors.
2013-10-28build: Factor common automakery out of backends’ Makefile.amsPhilip Withnall1-37/+12
This makes the backends’ build process so much more consistent, and reduces a huge amount of copy–paste automakery.
2013-10-28backends: Remove BackendFactory classesPhilip Withnall1-19/+6
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!
2013-10-25build: Disable some GCC warnings for generated C codePhilip Withnall2-0/+6
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
2013-10-25build: Whitespace cleanup in various Makefile.am filesPhilip Withnall1-8/+8
2013-10-21backends: Work around a Vala const-array null-termination bugPhilip Withnall1-1/+2
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
2013-09-24build: Generate backends’ GIR files using valac rather than g-ir-scannerPhilip Withnall1-31/+9
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
2013-07-08Revert "build: Don’t build Vala headers in a subdirectory unnecessarily"Philip Withnall1-3/+3
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.
2013-07-05build: Makefile whitespace fixesPhilip Withnall1-1/+1
2013-07-05build: Don’t build Vala headers in a subdirectory unnecessarilyPhilip Withnall1-3/+3
2013-07-05build: Remove generated C/H/vapi/stamp files from MAINTAINERCLEANFILESPhilip Withnall1-13/+2
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
2013-07-05build: Use target-specific VALAFLAGS rather than AM_VALAFLAGSPhilip Withnall2-34/+23
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
2013-07-04build: Remove redundant entries from GITIGNOREFILESPhilip Withnall1-6/+0
Now that git.mk has been modified to add better Vala support, these are unnecessary.
2013-07-02Link the support library GIRs against libfolksEmilio Pozuelo Monfort1-1/+4
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=703450
2013-07-01Add namespace and version to libfolks-libsocialweb GIRTravis Reitter2-0/+31
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=703402
2013-06-24Generate FolksLibsocialweb gir fileTravis Reitter1-0/+57
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=702490
2013-04-12Include ERROR_CFLAGS everywhere we compile C codeSimon McVittie2-0/+3
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>
2013-04-04folks, backends: use "small sets" instead of hash sets most of the timeSimon McVittie2-2/+3
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>
2013-04-03Do not explicitly link libfolks-internal.la into thingsSimon McVittie1-1/+0
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>
2013-03-18all Makefiles: don't ignore or clean .c files not corresponding to ValaSimon McVittie1-1/+1
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>
2013-03-13Don't do manual memory management for libsocialweb Contact structsSimon McVittie1-8/+2
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>
2013-03-12Do not assign to VALAFLAGSSimon McVittie1-2/+1
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>
2013-03-06Add -I$(top_srcdir) throughoutSimon McVittie2-0/+2
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>
2013-02-17Release version 0.9.0FOLKS_0_9_0Travis Reitter1-5/+5
2013-02-10Port folks to libgee 0.8.Travis Reitter5-11/+11
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
2012-12-30documentation: Document which yielding methods are safe to call concurrentlyPhilip Withnall1-0/+4
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.
2012-11-24lsw: Add enable|disable_persona_store api to libsocialweb backend.Jeremy Whiting1-9/+112
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=686673
2012-08-14Access static class members through class, not instance.Travis Reitter2-6/+6
This covers the libsocialweb backend. Helps: https://bugzilla.gnome.org/show_bug.cgi?id=681420
2012-08-14docs: Use correct Valadoc syntax for monospaced contentPhilip Withnall2-4/+4
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
2012-08-10docs: Various small fixes and expansions of documentationPhilip Withnall2-0/+4
• 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).
2012-07-24Revert "Change libgee dependency from 0.6 to 0.8."Jeremy Whiting4-5/+5
This reverts commit 5b5360bff7a61ef17173cbe35cc32712ca0fc329.
2012-07-24Revert "Port folks to libgee 0.8."Jeremy Whiting1-6/+5
This reverts commit e069bbe59dc54eb3595d8ee5c96aea4a36cff9aa.
2012-07-23Remove extra calls to set this._prepare_pending to false.Jeremy Whiting2-5/+2
2012-07-23Removed locks in trf-persona-store that are not needed.Jeremy Whiting2-34/+48
Minor style fixes based on review of previous changes.
2012-07-23Remove additional locks around this._is_prepared.Jeremy Whiting1-41/+43
2012-07-23Cut unnecessary Swf.PersonaStore._is_prepared locking.Travis Reitter1-77/+74
Helps: bgo#652637 - Don't hold locks across async calls
2012-07-06Port folks to libgee 0.8.Jeremy Whiting1-5/+6
Added hash_static and equal_static to AbstractFieldDetails. Use AbstractFieldDetails hash_static and equal_static where needed.
2012-07-05Change libgee dependency from 0.6 to 0.8.Jeremy Whiting4-5/+5
2012-06-28Add folks-internal to libsocialweb backend library vapi.Jeremy Whiting1-0/+1
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=679020
2012-06-27core: Add a profiling API and implement some profiling pointsPhilip Withnall3-0/+16
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.