New addon: pvr.mythtv.cmyth #60

Merged
merged 3 commits into from Oct 27, 2012

Conversation

Projects
None yet
4 participants
Contributor

fetzerch commented Oct 11, 2012

This PR adds the MythTV (cmyth) Addon.
Currently it support a MythBackend up to version 0.25 and the following features:

  • LiveTV
  • Playback of recordings (incl. marking recordings as watched on the backend + setting/reading last playback position + recording images support)
  • Basic support for timers
  • Transifex localization

The addon has been tested on Linux, Windows and MacOS.

Wiki: http://wiki.xbmc.org/index.php?title=PVR/MythTV
Forum: http://forum.xbmc.org/showthread.php?tid=110694

I squashed the addon related commits all together but kept the libcmyth related commits separated.

Let me know if you want me to change anything.

Thanks,
Christian

addons/pvr.mythtv.cmyth/Makefile.am
+if HOST_IS_OSX
+AM_LDFLAGS = -lboost_system-mt -lboost_regex-mt -ldl
+else
+AM_LDFLAGS = -lboost_system -lboost_regex -ldl
@opdenkamp

opdenkamp Oct 12, 2012

Owner

unless you have a terribly good reason for needing boost, this is a big no for me

@theuni

theuni Oct 12, 2012

Collaborator

and me. Boost can be a bitch to build on some platforms. Header-only is one thing, but libs are a no-go.

@fetzerch

fetzerch Oct 13, 2012

Contributor

Those are mostly historical reasons. The current codebase still uses boost for:

  • shared_ptr (which should be header only, I'd like to keep this, if ok)
  • unorderd_map (can be easily replaced by the slightly slower std::map)
  • bimap (for epg categories, should be replaceable by stl containers)
  • regexp (here we could add CRegExp to platform, and copy pcre from xbmc/lib (needed for win32))
    Is this the way to go?
Contributor

fetzerch commented Oct 13, 2012

Thanks for your comments.

@opdenkamp I Updated the PR according to your comment. The only boost dependency left is the header only boost::shared_ptr.

@theuni configure.ac has been changed to check for mysql lib (11d38eb) and for windows the internal mysql lib has been replaced by a downloaded one (in BuildDependencies) (ff81206, 8952556).

Cheers,
Christian

Collaborator

theuni commented Oct 15, 2012

@fetzerch thanks

Owner

opdenkamp commented Oct 16, 2012

@fetzerch it needs libmysqlclient and it's deps, which is a problem. you do not know whether it's available on the target system, what version is used, etc. that was the reason for dumping the curl dep.

Couldn't the configure.ac script be modified to try and detect the presence of libmysqlclient and refuse the build only the pvr.mythtv.cmyth add-on (but build all the others), if it wasn't found on the target system?

Collaborator

theuni commented Oct 16, 2012

The target system and the builder have nothing to do with eachother. It would have to build libmysqlclient.a itself (anda ll of its deps) and link against it. I assumed that's what was happening here, I suppose I should've looked deeper.

But if you're building from source on Linux, you'd want to be able use the system library version and not a bundled version. I understand that with add-ons, you want a single .zip file that has everything inside, e.g. for Windows etc, but there should at least be an option to build/link against system libraries.

e.g. I maintain the Fedora/RPM Fusion package, and we are planning to add the add-ons as an rpm package, in which case we'd want to strip out the bundled version of any system libraries and force all add-ons to use system libraries wherever possible, can that currently be done with these binary add-ons?

Collaborator

theuni commented Oct 16, 2012

I would strongly -1 that as imo it will end in a world of confusion after a while. It seems straightforward when there are only a handful of addons, but when you start to have deps of deps, maintaining cross-distro addons would be nearly impossible.

@cptspiff has thought long on the subject, he could give better insight (or smack me down).

@theuni perhaps we might be talking cross-purposes, but I wasn't proposing creating multiple versions of the add-ons in the repo, simply to allow binary addons to compile against system libraries when explicitly requested. In other words, the user would always install our binary rpm-packaged add-ons in preference to any that were distributed via the xbmc.org repo system.

When we package the PVR add-ons, we're going to have patch the add-ons to do this in any case, in order for them to pass review, but it would be better if upstream would make our lives simpler.

@ghost

ghost commented Oct 16, 2012

my opinon on this is that i rather not deal with it at all.

if peeps like fiveisalive want to build stuff for distro foo that's exactly what we want happening.
all we should do xbmc side is the code, integrate with apt/rpm/what/ever and manage the source repos.

i tried pkg-kit, it's a mess for several reasons, so my current solution is .py installer stubs.
a repository is then an add-on installer .py, an url to some addons.xml generated from the system repo backend listing and voila. we don't have to deal with building for the various linux distros and thus unload lots of work (other platforms we likely have to deal with anyways..) while we integrate nicely into the eco system and make maintainers happy.

note that there is nothing stopping you from setting up a static-only repo.

if I understand @cptspiff correctly, he's happy if the installer has an option to link to system libraries, but perhaps also can fall back to building an internal copy? is the libmysql issue the main thing holding this going in at this point?

Contributor

fetzerch commented Oct 21, 2012

@opdenkamp I've made the build of this addon (or better addons with dependencies) configureable, as discussed on irc. Let me know your opinion about this.

Owner

opdenkamp commented Oct 22, 2012

looks ok to me but haven't tested yet.
@cptspiff @theuni are you ok with this too?

@ghost

ghost commented Oct 23, 2012

sure. i don't think the freeze no the pvr repo can be as "hard" as on the main repo, at least not this cycle..

seems like we're good to go on this?

Owner

opdenkamp commented Oct 25, 2012

@fetzerch could you squash the relevant commits, so the new add-on is added in 1 single commit, and the other changes are in separate commits. thanks.

Contributor

fetzerch commented Oct 25, 2012

@opdenkamp squashed, but not sure if this is what you wanted. Did you mean I should squash only the build option commit with the addon itself, and still keep cmyth + gitignore separated?

fetzerch added some commits Oct 25, 2012

[project] Added option --enable-addons-with-dependencies (that defaul…
…ts to disabled)

Build addons with external dependencies only when this option is set.

opdenkamp pushed a commit that referenced this pull request Oct 27, 2012

Merge pull request #60 from fetzerch/release-0.4
New addon: pvr.mythtv.cmyth

@opdenkamp opdenkamp merged commit 8baca1e into opdenkamp:master Oct 27, 2012

Owner

opdenkamp commented on 3032afd Oct 27, 2012

@fetzerch and of course i only noticed this after pulling and running a git clean -xfd...
makefiles aren't created after this commit on linux with autoconf 2.68

Contributor

fetzerch replied Oct 27, 2012

@opdenkamp sorry! I tested this quickly (copied the dummy part from xbmc itself). Filed a PR with a fix (#72).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment