kimagecache.h
Alex Merry
kde at randomguy3.me.uk
Thu Dec 26 17:08:12 UTC 2013
On 26/12/13 16:42, Kevin Ottens wrote:
> On Thursday 26 December 2013 15:47:49 Alex Merry wrote:
>> There are three possible solutions that I see to this:
>> 1. just #include <kshareddatacache.h> in kimagecache.h, on the basis
>> KImageCache is useless without linking against KCoreAddons anyway
>>
>> 2. do some CMake magic to only do (1) if the current target is linked to
>> KF5::CoreAddons
>>
>> 3. move KImageCache to another framework that depends on KCoreAddons
>>
>> Bear in mind that we can put KSharedPixmapCacheMixin its own header if
>> we actually think it might be useful independent of KSharedDataCache.
>>
>> I would argue against (2), on the basis that it would break things for
>> any users that do not use CMake, and that sort of magic is fairly
>> fragile. (1) is, I think, a better solution than (2).
>>
[snip]
>> What do you think is the best solution?
>
> I think your point against (2) is fair, although I don't fancy it much let's
> go for (1) then as the "least bad" solution.
Well, it's not like KImageCache itself is any use without KCoreAddons.
Like I said before, we can put KSharePixmapCacheMixin in its own header
file if we think people will actually use it (we don't even have to make
that decision until someone comes to us and says they do).
It would be nice to be able to use CMake magic to produce helpful error
messages; I think I can see a possible way to do that (exporting defines
with both the KF5::CoreAddons and KF5::GuiAddons targets, and producing
a #warning if we find the GuiAddons define but not the CoreAddons define).
Alex
More information about the Kde-frameworks-devel
mailing list