Login at Kodi Home

FernetMenta · (This post was last modified: 2015-02-25, 19:31 by FernetMenta.)

**h.udo** · 2015-02-23, 17:28

Please change pvr.vuplus to the addon you're working with.

Fork https://github.com/opdenkamp/xbmc-pvr-addons

Clone the fork to your disk

Code:

git clone [email protected]:<your username>/xbmc-pvr-addons.git

Create a copy of the freshly cloned repo. In case things go south you can start over.

Code:
cp -r xbmc-pvr-addons/ pvr.vuplus/

Go to the root folder of new repo

Code:
cd pvr.vuplus/

Filter what we what to keep

Code:
git filter-branch --prune-empty --subdirectory-filter addons/pvr.vuplus/ master

Remove unneeded files and folders

Code:
git rm Makefile.am

git rm -r project/

Rename old stuff

Code:
git mv addon/ pvr.vuplus/

cd pvr.vuplus/

git rm addon.xml.in

We're missing some files but fortunately notspiff and Montellese already took care of that.

Go to https://github.com/notspiff?tab=repositories or https://github.com/Montellese?tab=repositories, click the repository you're interested in and download the zip file.

Open the file and copy debian folder and every file in root folder (CMakeLists.txt, FindTinyXML.cmake, etc) to the new root folder of your repository. Only one more file missing. Find addon.xml inside pvr.vuplus folder and copy it to pvr.vuplus folder of your repository.

At this stage, everything we need is in place. Let's update the repo.

Add new/changed files to git. You must be on repository root folder, I think... can't remember

Code:
git add *

Commit the changes

Code:
git commit -m "Sync with cmake"

Go to your GitHub account and create a new pvr.vuplus repository

Change origin to new repository

Code:

git remote set-url origin [email protected]:hudokkow/pvr.vuplus.git

Verify new remote origin

Code:
git remote -v

Push to new origin

Code:
git push origin master

or simply

Code:
git push

Done! You should end with something like https://github.com/hudokkow/pvr.vuplus. More importantly, git history is preserved.

I'm sure there's probably more simple ways to achieve the same and, as usual, improvements and suggestions are very welcome.
Thanks FernetMenta for the tips!

h.udo

FernetMenta · 2015-02-23, 19:20

It may be a good idea to double check the "sync with cmake" change with the original code. Just to make sure nothing has been lost/added unintentionally.

**h.udo** · 2015-02-23, 19:31

Ah! You're right!

I forgot to update the #includes. Probably missed some more things. Crap!

Thanks.

**xhaggi** · 2015-02-23, 21:30

Awesome work guys Wink

Does it means that each addon repo will be owned by its author and he only needs to submit a PR to bump his addon (change the addon cmake txt in the xbmc repo)?

FernetMenta · 2015-02-23, 21:59

(2015-02-23, 21:30)xhaggi Wrote: Awesome work guys

Does it means that each addon repo will be owned by its author and he only needs to submit a PR to bump his addon (change the addon cmake txt in the xbmc repo)?

That is my idea of how it should work but discussion goes on. Others think that it may be good to fork the original repos and point cmake to those.

janbar · 2015-02-24, 18:13

Thanks guys for the tuto. I recovered full history and authors would be happy.

**h.udo** · 2015-02-24, 18:37

ironic_monkey · 2015-02-25, 17:49

Probably a good idea to update the first post.

FernetMenta · 2015-02-25, 19:32

(2015-02-25, 17:49)ironic_monkey Wrote: Probably a good idea to update the first post.

done

**dhead** · 2015-02-25, 21:36

I'm packaging the alpha releases for testing (and translating) on my Arch Linux laptop.

I think it might be a good idea to be able to transfer the git git-revision as parameter without making changes in the [addon].txt, I'm sure addons developers won't bother with bumping the git hash/tag for every alpha so this will be quite useful.

FernetMenta · 2015-02-25, 22:33

I suggested using a branch, not a particular revision: https://github.com/xbmc/xbmc/pull/6227#i...t-75913272
Not sure about the down sides.

**dhead** · 2015-02-25, 23:12

@FernetMenta

Lets say I'm building from the alpha2 tag when the merge window of alpha3 is open, a pvr api change has been merge to the I*** branch at an addon's repo (following changes in alpha3 merged to kodi), this might cause an addon runtime or build time breakage, so I'm not sure only having branch as parameter to the cmake system is a good idea.

**dhead** · 2015-02-25, 23:14

p.s. I'm assuming you don't expect addons developers to create a branch for each alpha release.

ironic_monkey · 2015-02-26, 10:03

For packaging i reckon it is best to use standalone builds rather than the in-tree buildsystem which really only is necessary for cross builds and windows. The install target of kodi installs everything needed from kodi to build the addon. Since you be using native packaging tools you are free to specify what you build however you want.