Login at Kodi Home

oliv3r · 2012-07-19, 13:58

Hi all,

I was having some crosscompile issues with libdvdnav and noticed that there's quite some 'normal public' libraries included in the XBMC git repository.

Why is that?

I can understand that 'in ye old days' it was handy for getting started quickly, but now, it also adds an maintenance burden. This should only be an issue at all for developers. Users would get a binary or use a CD (distro) that packages everything for the user to properly use, so any library dependencies would be resolved.

Is it simply a matter 'supply a patch and we can fix it' or is there some life-threatening reason the libs need to be inside of XBMC? I belive you can have 'sub'-repositories within a git repository partially solving issue in that case?

Oliver

**Memphiz** · 2012-07-19, 15:25

There are some really special adaptions to these librarys which are specific to XBMC and won't be taken upstream. Most of them are allowing the usage of our VFS for accessing files via all supported protocols of XBMC with libs which are normally only supporting local files.

oliv3r · 2012-07-19, 16:34

That does make things more difficult, e.g. patched libraries are thus absolutely needed?

So the VFS would have to be re-written into a structure that would be supportable everywhere...

Thank you for your information. Is there a list of these libs? I did check on github but saw some commits where over a year old (libdvdnav).

**Memphiz** · 2012-07-20, 00:01

everything in lib/

davilla · 2012-07-20, 04:53

Our libdvdnav is quite old from upstream, it needs a complete overhall to identify our patches to it so that merges from upstream are easier. Similar to how we track our FFMpeg patches.

I must confess that I made this difficult by not resisting the urge to 'clean up' some local formatting mess that I ran across when I last did the update. My bad and so it becomes my job to sort it out sometime.

'sub'-repositories within a git repository don't magically solve all problems, we already discarded that option.

Rest assured that while the names of these libs might match "normal public' libraries, they are not the same thing inside.

The bottom line is, the libs you see in xbmc are known as internal libs, they are there not because we are lazy devs but because they contain necessary patches to the operation of xbmc. These are present because a) upstream refuses them b) there is no upstream or c) for easy build/install on older distros.

oliv3r · 2012-07-20, 08:53

So ideally, libs that fall into category a; will need to have patches 'extracted' and then have upstream + patch basically?

jmarshall · 2012-07-20, 09:06

Correct. If you can get rid of any of the libs there with a clean upstream version then we don't need the sources there at all - we depend on a heap of other libs that aren't included in here already anyway.

So if you or anyone else wants to take some time to compare with public sources + do up patch sets for review that'd be most welcome.

Cheers,
Jonathan

oliv3r · 2012-07-20, 09:53

I may take a look into that. Thanks for clarifying all that Smile