Some vague efforts have been made to get dbus to build with builddir != srcdir, but they haven't been taken very far (e.g., not as far as actually working). There is also a lot of gunge supplying ABSOLUTE_TOP_BUILDDIR to the tests. (a) This is unnecessary; @abs_top_builddir@ already exists (b) This is wrong: several should be @abs_top_srcdir@ gcj/org/freedesktop/dbus/Makefile.am tries to get it right and fails: unwisely trying to imitate something from the autotools, it plays with -I$(srcdir)/$(top_builddir), but it's in the wrong place, and the result is merely a broken ooncatenation of paths. Following an almost universal convention, nobody has bothered making Doxyfile work properly in this case. Weirdly, there already is a Doxyfile.in, used for other configuration purposes, but the (easy-as-falling-off-a-log) changes to handle a separate build directory have not been made. Here are two patches. (a) Patches for CVS (the Real Thing) (b) A patch for the *RELEASE* (since I was working from the 0.60 release) which does the corresponding magic with configure and <various>/Makefile.in files. *** IMPORTANT NOTE *** Some built files are lying around in the release, for no very good reason. This is obviously pointless: in fact, it's wicked as well, because it breaks building in a separate build directory. One can't invoke 'make clean' to get rid of them, because the release doesn't have the Makefiles, but one can't leave them there either. One may even end up (re-)building the file because the Make rules specify that it ought to be re-built, but the old one will still be used! The default rules for GNU make will always pick up an object from the source tree in preference to something (even more recent) in the build tree. The offending files are: test/data/valid-config-files/debug-allow-all.conf test/data/valid-config-files/debug-allow-all-sha1.conf test/data/valid-service-files/debug-echo.service test/data/valid-service-files/debug-glib.service test/data/valid-service-files/debug-python.service test/data/valid-service-files/debug-segfault.service test/data/valid-service-files/debug-shell-echo-fail.service test/data/valid-service-files/debug-shell-echo-success.service *** IMPORTANT NOTE 2 *** The build process seems to use installed headers in preference to the local headers, if it finds them in the usual INCLUDE search-path. I haven't exerted myself to make this work differently, but it is certainly doable (gcc, at least, allows the usual search-path for #include <xxx.h>-type headers to be rewritten). This has got to be good for developers who may modify the headers!
Created attachment 4746 [details] [review] Allow build outside the source directory: the CVS sources patch
Created attachment 4747 [details] [review] Allow build outside the source directory: the release extra patch
Created attachment 4749 [details] [review] Allow build outside the source directory: the release extra patch
Comment on attachment 4746 [details] [review] Allow build outside the source directory: the CVS sources patch You change dbus-viewer to be found in top_srcdir, but it's a compiled object; does libtool want the srcdir name or something? Looks fine to me, assuming it works and make distcheck still works.
The relocation of dbus-viewer was my mistake. The dbus test fails for me for other reasons (I get multiple assertion failures at dbus-signature.c line 192). This change was added on autopilot and left in by oversight. This is now the only failing test I see: I'll look into it a bit harder.
Created attachment 4814 [details] [review] CVS sources patch, without the mistaken hunk The dbus test still fails for me. I get the same assertion failure as before, with no visible difference between builddir=srcdir (unpatched sources) and builddir != srcdir (new sources). I've removed the hunk which made the script look for dbus-viewer in the source tree - I agree that was a mistake. I've checked the others, and they all still look all right.
I'm wondering if this is still an issue as we did some fixes. Putting on thr 1.0 blocker.
Picked a few pieces out of this patch and applied it to head. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.