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 <ottw...@gmail.com> wrote: > On 21.03.2018 01:16, David Edmundson wrote: > > > > On Tue, Mar 20, 2018 at 9:43 AM, Michael Heidelbach <ottw...@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.cu...@kde.org, http://cukic.co/ gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3 45DF C9C5 77AF 0A37 240A