•  Previous
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 13
  • Next 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
Develop PVR addons with new cmake build system
#31
Awesome, thanks, I got it set up just the way I wanted now.
Reply
#32
Sorry to ask such a basic question, but I'm new to cmake: would someone be able to give me a hint on how to setup a cmake toolchain file to cross-compile these addons?

I'm just trying to figure out what I need to add to h.duo's instructions for native compiliation. I guess I need a .cmake file to pass to cmake with -DCMAKE_TOOLCHAIN_FILE ? Anything else?
Reply
#33
have a look at the in-tree build system. it's doing precisely that... a cmake toolchain is generated as part of the tools/depends configure.
Reply
#34
this may be the place to ask my question too. in pvr.wmc we have a clientversion.h file that we were previously updating the version in (as well as the addon.xml.in file) and constantly having issues when other people did changes and bumped the xml file without realising there was a header file as well. Is it possible to have the new build system generate our clientversion.h file (or similar) or replace a token in it or whatever, based on the version in the addon.xml file?
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
#35
of course, want me to prepare it ? i did in any case. pull https://github.com/notspiff/pvr.wmc/comm...entversion

i cannot send a pr as my repo aint a fork and i cba to refork right now. but it's based on kodi-pvr/pvr.wmc master so it should pull clean (git pull https://github.com/notspiff/pvr.wmc generate_clientversion).

general cluestick: configure_file(infile outfile @ONLY). placeholders are replaced with the value of the equivalent *cmake variable*. the build_addon macro makes the version available as <PREFIX>_VERSION where PREFIX is given as a parameter (WMC in this case).
Reply
#36
im hpapy to give it a try but would appreciate a bit more of a clue Big Grin the configure_file command seems OK, assumedly i cdreate a template file somewhere (eg clientversion.h.in), containing @[email protected] parameter, and then add a call to configure_file to copy the template file to the right header file and do the parameter replacement, effectively generating the clentversion.h header file. However what im not sure of is if there is already a @[email protected] parameter in existence within cmake that somehow magically knows our pvr.wmc version, or do we have to read it in from the addon.xml file? if so, how to do that?

Also I guess the other thing Im not quite understanding is that if we are using visual studio (as we are windows devs) which I take it we now generate a VS solution/project via running cmake, and if we had this custom cmake command to generate out c++ file that contains the version and is compiled into our addon, would cmake then turn that into a Visual Studio post build event in the VS sln/csproj that it generates, or does it only work when executing cmake on the build servers (and thus our windows IDE/development would infact fail to compile because the header file would be missing, since nothing had generated it?)
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
#37
read my updated post and commit. it's the full thing. the build_addon() macro reads from addon.xml for you and makes it available.

the outlined solution happens at configure time (i.e. when you call cmake) and won't pick up a change to addon.xml on build time. it you want it done on build time, i can do that as well, easily doable, just some slightly more annoying syntax involved.
Reply
#38
top commit in the branch now does the generation as a build step. touch clientversion.h.in or addon.xml and it's regenerated.
Reply
#39
Cool thanks! I'll try and test it tomorrow
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
#40
I have a quick question about -DADDON_SRC_PREFIX.

I'm trying to piece together a readme for compiling game add-ons with the new cmake build system (https://github.com/kodi-game/game.libret.../Readme.md ) and it looks like I need to set -DADDON_SRC_PREFIX=$HOME/workspace, where $HOME/workspace is the dir I cloned the add-on to, i.e.

Code:
cd $HOME/workspace
git clone https://github.com/kodi-game/game.libretro.git

Is this right, or should it be -DADDON_SRC_PREFIX=$HOME/workspace/game.libretro? Is -DADDON_SRC_PREFIX even used? I get cmake warnings that this var is unused.
Reply
#41
ADDON_SRC_PREFIX must point to the parent dir, so if you do:
Code:
cd $HOME/workspace
git clone https://github.com/kodi-game/game.libretro.git

then -DADDON_SRC_PREFIX=$HOME/workspace
Note that the git dir (game.libretro) must match the addon definition in project/cmake/addons/addons/game.libretro/game.libretro.txt

edit:
you probably also want to pass the list of addons you want to build with -DADDONS_TO_BUILD="game.libretro game.whatever some.other.addon"
Reply
#42
thanks, so my readme is correct (at least for that one detail Wink )

my game.libretro.txt file is:

Code:
game.libretro https://github.com/kodi-game/game.libretro 88bf57c

the add-on compiles and runs so I think I'm doing this right
Reply
#43
great. If you want to proof that your local copy is used, just add this line to your adons CMakeLists.txt
Code:
message(FATAL_ERROR "test, bailing out")

and run make. It should then throw this error.
Reply
#44
I tried to compile using the new receipe and its quite unobvious for an non dev:

[quote]
cmake -DADDONS_TO_BUILD=pvr.demo -DADDON_SRC_PREFIX=/home/xbmc/progs/src -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/xbmc/progs/src/xbmc/addons -DPACKAGE_ZIP=1 /home/xbmc/progs/src/xbmc/project/cmake/addons
[\quote]

-DCMAKE_INSTALL_PREFIX install the binary addon in the xbmc source tree, why not in the installed tree? So you must redo an install to have it really installed on the target directory. So please document the full procedure

In addition, the current kodi docs/README.linux fails at make -C tools/depends/target/binary-addons PREFIX=/usr/local)
In addition, the current kodi docs/README.pvr still reference the old tree
In addition, pvr.hts reference non existing fields in epg (iYears) and channel_group(iPosition)

diff --git a/src/Tvheadend.cpp b/src/Tvheadend.cpp
index 7cb1047..3d0fd13 100644
--- a/src/Tvheadend.cpp
+++ b/src/Tvheadend.cpp
@@ -130,7 +130,7 @@ PVR_ERROR CTvheadend::GetTags ( ADDON_HANDLE handle )
tag.bIsRadio = false; // TODO: support for radio channel groups.
strncpy(tag.strGroupName, it->second.name.c_str(),
sizeof(tag.strGroupName));
- tag.iPosition = it->second.index;
+ // tag.iPosition = it->second.index;
tags.push_back(tag);
}
}
@@ -684,7 +684,7 @@ void CTvheadend::TransferEvent
epg.strCast = NULL; /* not supported by tvh */
epg.strDirector = NULL; /* not supported by tvh */
epg.strWriter = NULL; /* not supported by tvh */
- epg.iYear = 0; /* not supported by tvh */
+// epg.iYear = 0; /* not supported by tvh */
epg.strIMDBNumber = NULL; /* not supported by tvh */
epg.strIconPath = event.image.c_str();
epg.iGenreType = event.content & 0xF0;
Reply
#45
good thing non-devs is not a concern then ! ;>

really, forget about the in-tree build unless you are crossing. just build it as normal software

1) execute make install for kodi to install bindings and cmake helpers.
2) build and install kodi-platform from https://github.com/xbmc/kodi-platform

you then build them addons completely like other software. and install them wherever you want, however you want.
Reply
  •  Previous
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 13
  • Next 



Develop PVR addons with new cmake build system00