Tomahawk Integration Status

[Matěj Laitl]

On 19. 11. 2012 Lucas Lira Gomes wrote:
> as the only GSoC project that isn't yet fully finished, I believe that I
> owe you an explanation about its current status. I had worked a lot in it
> this weekend and got several things done.

Thumbs up!

> To begin with, Libtomahawk often slows down my plans with some unexpected
> but necessary last-minute refactoring. At the moment, for instance, I'm
> solving some problems with tomahawk's #defines mess. After that, I expect
> it to be "ready" for third-party usage.

I totally understand. I think tomahawk guys should be really grateful for you 
cleaning up their buildsystem & more clean-up work.

> Likewise, It worth to mention that I had worked hard to
> minimise unnecessary dependencies and that was one of the things that
> delayed my original scheduled even more. That means, considering current
> implementation, we'll need to include libechonest, libattica and quazip
> among our own dependencies.

Well-spent time. Don't we already depend on libattica? No, it seems not, but 
by kdelibs 4.9.3 unconditionally depend on libattica >= 0.1.90, so this one 
shouldn't hurt much.

> With regard to how libtomahawk will be shipped, It'll be like our
> amaroklibs. In other words, the user/packager would be able to choose at
> compile time if he/she want to build only libtomahawk or the full tomahawk
> app. Furthermore, Its headers files are already installed, so it'll be just
> as an ordinary shared library at the end.

Good. I think most distros (for sure those Debian-based) will build the whole 
player, but split the resulting binary package into lib and player. Would it 
be possible?

> In spite of that, I believe I'm getting closer to a satisfactory state.
> Just need some more work.
> 
> So, that's all. Feel free to ask about anything you want to.

Thanks for the update! Don't get discouraged by realizing things need much 
more work, it's always like this.

Cheers,
		Matěj