soprano cmake patch - making backends optional

Maciej Mrozowski reavertm at poczta.fm
Wed Jan 28 09:21:30 CET 2009


Hi

I believe this should rather go to Sebastian Trueg, but as far as it's 
buildsystem related I decided to post it here.

Attached patch just adds cmake options ENABLE_Redland, ENABLE_CLucene and 
ENABLE_Sesame2 to make it possible to explicitly disable building some 
backends, even when required dependencies are present in system.
So far script just autodetects dependencies and enables everything available 
(and it's not really desired on source based distributions - hence the patch).

And second issue, or rather question to Sebastian - what does raptor RDF 
parser actually do, is it really used and why it's bundled in the same cmake 
finding module with redland database backend?
To make it worse, raptor parser was recently added as requirement to nepomuk - 
which I promptly removed from our Gentoo packaging scripts only to notice that 
nepomuk (searching and indexing - with both clucene and sesame2 enabled in 
soprano) builds and seems to work fine *without it*.
I'm removing raptor requirement using following sed - if you think that this 
is acceptable, I can provide proper patch for you.

sed -i -e 's/ AND SOPRANO_PLUGIN_RAPTORPARSER_FOUND//g' (on toplevel 
CMakeLists.txt in kdebase-runtime)

(so that nepomuk client is compiled when Soprano_FOUND AND Nepomuk_FOUND AND 
STRIGI_STRIGIQTDBUSCLIENT_LIBRARY AND SOPRANO_BACKEND_FOUND)

Besides, I would like to ask about dependencies here - what is *actually* 
required for functional semantic desktop in KDE4?
Correct me if I'm wrong (I am probably):
- indexing engine (soprano with CLucene support)
- full-text search engine (strigi with Clucene support)
- one of database backends (soprano with either redland or sesame2 or both)
- anything else?

Using trial-error approach we reverse engineered those deps so that, when user 
wants semantic desktop functionality we require to:
- build strigi with qt4 and dbus support
- build strigi with CLucene (just in any case by default)
- build at least one Soprano backend (redland or sesame2)
- build soprano with CLucene (just in any case because we don't know whether 
there's any other working backend substitute)
- build kdelibs with Soprano support (enabled building nepomuk library)

To be honest, I feel pretty lost in here, it may be caused a bit by overusing 
the word 'backend' by upstream :)
Is there any relation between strigi compiled with CLucene and soprano 
compiled with CLucene?
Where I can find some comprehensive docs that gather all those tools in one 
place and explain relations and build/runtime dependencies between them?

A side note (in case someone didn't like our "suboptimal packaging") - we're 
just trying to provide users with choices you give us via your buildsystem 
cmake options (splitting packages is an exception), and we're interested and 
willing to help in keeping it robust.

Thanks in advance

-- 
regards
MM


----------------------------------------------------------------------
Speak Up. Angielski szybko i skutecznie. 3 miesiace nauki gratis.
Sprawdz. >> http://link.interia.pl/f2019
-------------- next part --------------
A non-text attachment was scrubbed...
Name: soprano-make-optional-targets.patch
Type: text/x-patch
Size: 14110 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090128/6a6a6730/attachment.patch 


More information about the Kde-buildsystem mailing list