Nepomuk as hard dependency in future?

[George Kiagiadakis]

On Sat, Oct 17, 2009 at 1:19 PM, Peter Penz <peter.penz at gmx.at> wrote:
> Hi,
>
> currently Nepomuk is an optional dependency. There are widgets that have
> extended functionality by using Nepomuk, but also can live without Nepomuk (e.
> g. Dolphin has a MetaDataWidget - without Nepomuk just less meta data are
> shown).
>
> One problem is that this requires a lot of #ifdef HAVE_NEPOMUK code. While
> this is just a nasty detail in the implementation, it gets to a real problem
> especially in header files for kdelibs, that use a Nepomuk interface like
> this:
>
> class MetaDataWidget : ...
> {
>    ...
>    public:
>        QList<Nepomuk::Tag> tags() const;
> };
>
> Using #ifdef HAVE_NEPOMUK code is no option as this would be BIC. If Nepomuk
> would be a hard dependency (but for sure can be turned off during runtime as
> always), this problem would be a no-brainer (-> tags() would just return an
> empty list if Nepomuk is turned off).

I don't see why this is not an option. Of course it would be BIC, but
that is what we have now as well. If you build for example dolphin
with nepomuk support and try to link it to a kdelibs version that
doesn't have nepomuk, it will fail. In addition, look at Qt. They are
doing the same thing with qfeatures.h. They allow you to #ifdef out
parts of Qt that you don't need and build a custom minimal version
that only includes what you need. Of course, if you use this
mechanism, the resulting libraries are BIC with any other Qt version
out there, but that's not a reason not to have this mechanism
available.

In general I'm not in favor of hard dependencies, but ok, if you want
to make nepomuk a hard dependency at some point in the future, no
problem by me, but please do it only after we have a usable soprano
backend. Rumors say that virtuoso is going pretty well, so If virtuoso
is ready for release with kde 4.4, then maybe it is possible to make
nepomuk a hard dependency for 4.4... ;)

Regards,
George