Created attachment 238190 [details] [review]
build: explicitly check for and link to gmodule

From: Alexandre Rostovtsev <tetromino@gentoo.org>

Needed to prevent underlinking failure with ld.gold and recent versions
of libsocialweb's dependencies.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=686503
[adjusted to use gmodule-no-export, not gmodule -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

(In reply to comment #1)
> build: explicitly check for and link to gmodule

Er, sorry, meant to attach that to Bug #686503.

Created attachment 238192 [details] [review]
autogen.sh: don't configure if NOCONFIGURE is set

As proposed in http://people.gnome.org/~walters/docs/build-api.txt
and widely supported in GNOME. This is particularly useful if you're
about to configure for an out-of-tree build.

Also use "set -e" to avoid having to scatter "|| exit 1" everywhere.

Created attachment 238193 [details] [review]
configure.ac: set GLib 2.26 as minimal version

libsocialweb claims to support GLib as old as 2.14, but there's no
macro for that; 2.26 is the oldest version for which a version macro
exists.

In particular, this gets rid of deprecation warnings about GValueArray.

---

A later target version up to 2.30 would also be fine, as would targeting 2.32, 2.34 or 2.36 after avoiding GValueArray.

Created attachment 238194 [details] [review]
Build out-of-tree successfully

If you're building out-of-tree from git, the generated C code
corresponding to the XML in interfaces/ lands in the builddir, not
the srcdir; but if you're building out-of-tree from a tarball,
it lands in the srcdir, not the builddir. Look in both.

---

distcheck still doesn't work for gtk-doc-related reasons, but I'm not going to get into that now.

Review of attachment 238192 [details] [review]:

Yes.

Review of attachment 238193 [details] [review]:

Oh, that's a neat feature I'd never seen before.

Review of attachment 238194 [details] [review]:

My only comment is WAT.

Created attachment 238195 [details] [review]
Build out-of-tree successfully

If you're building out-of-tree, the generated C code
corresponding to the XML in interfaces/ ought to be in the builddir;
so it needs to be #include'd from there.

However, if you include the generated source in tarballs,
that satisfies the "make" dependency and the files won't
necessarily be rebuilt, resulting in the build failing.
To avoid that, don't distribute generated source.

---

(In reply to comment #8)
> Review of attachment 238194 [details] [review]:
> 
> My only comment is WAT.

You might find this alternative, which deals with the root cause better, to be less wtf?

Right, I understand the situation now - having a bit of a brainfart day today.

I think I prefer shipping generated code and looking in both places to not shipping the generated code.

(In reply to comment #10)
> I think I prefer shipping generated code and looking in both places to not
> shipping the generated code.

Really? Any particular reason? I'm a big fan of having any given file be either source or built, not a mixture of both :-)

They're in CLEANFILES, so "make clean" is going to delete them anyway.

Thinking about it again, I'm not sure whether Attachment #238194 [details] works correctly if you have the generated code in the ${srcdir} (i.e. are building from a tarball), but then update something (i.e. you're a distribution applying a patch): I think it will prefer the outdated copy in the ${srcdir} over the one in the ${builddir}. The -I...${builddir} should probably come before -I...${srcdir}.

Hm.  I like your argument - the point that clean wipes them anyway is a good sign that they shouldnt' be disted.

Review of attachment 238195 [details] [review]:

Approved.

You're probably now the libsw maintainer, btw.

All applied to master, commits 6199dc36, 8346001, dc44b05e.

(In reply to comment #13)
> You're probably now the libsw maintainer, btw.

Does this mean it's sufficiently obsolete/unmaintained/deprecated that Folks should stop using it? I only compiled it at all because Folks can't distcheck without it...

Rob and myself are not working on it anymore, but it does still work...