Some --disable-backend-XXX option combinations fail

[Olly Betts]

So far I found:

• Disabling the remote backend makes the replication server fail to build.
• Disabling flint means that some tools in bin fail to build.

I suspect the two above at least don't affect 1.0.x (no replication; I think the tools problem is that the chert stuff currently uses flint routines, which isn't great but works for now), but I didn't check this.

I fixed some easy problems with other options, but there may still be problems with other options, or certain combinations.

---

From #603 (closed as a duplicate of this):

Unless one ./configure's xapian-core 1.2.12 with both --enable-backend-flint and --enable-backend-remote, the build fails. The downstream bug can be found at

​https://bugs.gentoo.org/show_bug.cgi?id=433611

[Olly Betts]

This can be fixed after 1.2.0 is released.

[Olly Betts]

Testing showed that none of these options are useful in 1.2.0 - using any of them results in a compilation failure.

That's a major regression from 1.0.x where most combinations worked, so marking for 1.2.1. I've already committed a couple of improvements, and am working on more.

[Olly Betts]

Well, some of them now work.

The rest seems to be a nightmare - replication uses lots of remote backend stuff, as do serialise methods. I started to add #ifdef-s, but it seems too complex to be worthwhile, and is too easy to regress unless we're prepared to check all 32 build combinations regularly. We can probably trim that down some, but it's likely to be at least 10 to cover combinations likely to be problematic.

So I'm tending to think we should seriously consider removing these options. They're useless for binary packaging (since somebody will want any given backend), so the only real use I can see is for people building a custom "small" Xapian for use of restricted hardware (e.g. embedded systems). If we want to assist that, the best way is probably an option which gives you just one disk based backend, and perhaps a second which disables the remote backend and replication. But perhaps we should worry about this if/when we actually have someone wanting it. It seems nobody is regularly using the current options to disable backends as I've generally found them broken when I've tried them.

[Olly Betts]

Throwing back in the 1.2.x pot.

[Olly Betts]

Moving to 1.3.x now.

[Olly Betts]

Not something we'd hold 1.4.0 for.

[Olly Betts]

--disable-remote now works with git master - I've made it also disables replication (not entirely logical from a user point of view, but they share most of the network code so it makes sense from the implementation side).

I've also fixed various issues so disabling all backends builds cleanly.

I've not tested all possibly combinations though. Not planning to backport to 1.2.x.

[Olly Betts]

--disable-backend-remote still fails if a disk-based backend is enabled (due to replication code in the disk-based backends).

[Olly Betts]

--disable-backend-remote was fixed for 1.4.6 by 8876c2699b654100cc591a9c0a4e5f8c7a647d6a.

At this point I believe all combinations actually work on both master and RELEASE/1.4 branch, so I'm going to close this as I don't think there's currently any useful further action. Adding CI builds for 2ⁿ combinations of --disable-backend-XXX options just isn't a justifiable use of CI resources - n is only 4 on master currently but that's still 16 builds, which is about as many again as we currently have.

If people hit useful combinations that don't work they can just open a new ticket.