Experimental class in baloo

[Ivan Čukić]

Hi,

Is this a class that is supposed to be available in the library (.so
file) - to be used in applications that use baloo, or is it only a
class in the backend?

If it is the second case (which I guess it is since I don't see the
symbols exported in libKF5Baloo.so), then this should not be a problem
- it is not a part of the API nor the ABI.

Cheers,
Ivan


On Wed, Mar 21, 2018 at 3:03 PM, Michael Heidelbach <ottwolt at gmail.com> wrote:
> On 21.03.2018 01:16, David Edmundson wrote:
>
>
>
> On Tue, Mar 20, 2018 at 9:43 AM, Michael Heidelbach <ottwolt at gmail.com>
> wrote:
>>
>> Hi!
>>
>> I've recently introduced a new class for baloo. It is mainly for
>> debugging. As it is accompanied with a command line tool it may be useful
>> for users too.
>>
>> It is still in an experimental state and it's likely I'll wish to change
>> the public interface.
>>
>> 1) Is it possible to mark that class as experimental for some time and
>> have the allowance to chance the interface?
>
>
> Once you've exported symbols in the same library as baloo...not really.
>>
>> 2) If so, what is the best way to communicate that?
>
> If it's purely for debugging, stick it behind some optional CMake definition
> so only users who explicitly enable it have the header installed.
>
>
> David
>
> Thank you for your reply, David.
> In this case I would like to hide it (and the command line tool) at least
> until 5.46.
> I'm not very knowledgeable with CMake. I guess sticking it 'behind some
> optional CMake definition' will also account for it not being part of the
> library. I've never done this before can you some help or an example please.
>
> Michael
>
>



-- 
KDE, ivan.cukic at kde.org, http://cukic.co/
gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3  45DF C9C5 77AF 0A37 240A