compilation fails with 'uuid.h: no such file' when configured with no back end.

[Anthony G. Basile]

Configuring xapian with

./configure --disable-backend-brass --disable-backend-chert --disable-backend-flint --disable-backend-inmemory --disable-backend-remote

The build fails at compile time with:

In file included from ./backends/brass/brass_version.h:27:0,
                 from api/compactor.cc:53:
./common/safeuuid.h:57:19: fatal error: uuid.h: No such file or directory
compilation terminated.
make[2]: *** [api/compactor.lo] Error 1
make[2]: Leaving directory `/var/tmp/portage/dev-libs/xapian-1.2.8/work/xapian-core-1.2.8'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/dev-libs/xapian-1.2.8/work/xapian-core-1.2.8'
make: *** [all] Error 2

This is because of line 694 of configure.ac where the header check is done in

case $enable_backend_flint$enable_backend_chert$enable_backend_brass in

I didn't attach a patch because I'm not sure if at least one backend must be defined or the header check should be made with all backends disabled.

[Olly Betts]

It doesn't seem a very useful configuration, but libuuid shouldn't be needed in it.

I'd say the bug is that we try to use the header in this case, and that most of the contents of api/compactor.cc should be #if-ed away if none of the relevant backends macros are defined.

[Dan]

What is the use case for no backends?

[Olly Betts]

Things like stemming and the unicode routines don't need a database. Or if you're only using the remote backend on a restricted memory/storage platform, you might disable all the disk based backends. I'm not sure if anybody actually cares about that sort of case though. AIUI, the reports from blueness are because gentoo expose these configure options to people installing packages.

If configure option combinations intentionally aren't supported, it would be better to flag them as an error at configure time than apparently accept them and then dying later.

The underlying issue is that there are a lot of combinations of backends enabled/disabled and regularly testing them all isn't an appealing use of time. I'm not sure what the best answer to this is.

[Anthony G. Basile]

AIUI, the reports from blueness are because gentoo expose these configure options to people installing packages.

Correct. Ironically a downstream bug was just filed:

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

We can fix the bug in numerous ways, but it really depends what combination of enabled/disabled back ends we want to permit.

[Olly Betts]

I'm really not convinced it's useful to expose these flags in gentoo.

I'm borderline on whether they're useful for us to have at all, but it seems unhelpful to strip them out in case someone does want a cut down build for a platform with limited storage. Even if they don't work currently in all combinations, some combinations do, and fixing others is easier than starting from scratch would be. But given the number of other things I have to work on, fixing them isn't a priority for me I'm afraid.

If you want to work on this particular combination, I'd suggest trying adding the #ifdef I mentioned in comment:2.

[Olly Betts]

I fixed the uuid-related issues and some others, and made the --disable-brass --disable-chert combination work on trunk in r16863.

Disabling all backends doesn't work still, but that's covered by #361.

The fix will need work to backport (there's flint in the mix too, and the compaction and check stuff has been reworked), and the risk/reward of changing 1.2 for this doesn't seem compelling. So I'm not intending to try to fix this on the 1.2 branch.