[graysky]

I read through this wiki page and found the instructions there to be outdated and lacking.  Is there a template one can use to flag a page as such?

[ronie]

already outdated? that page was updated just this morning :-)

instead of flagging it, why not update it / add the missing pieces of info? ;-)

[graysky]

@ronie I did update the intro but manually building is just silly.  Too many deps to manage by hand, files on the filesystem not tracked by pacman... makepkg or a building in a clean chroot is the way to go on an Arch system.  The instructions under the paragraph I added are missing info, details, updated deps, etc.  Not worth salvaging in my opinion.

[enen92]

Why not contributing to the build docs in GitHub instead of using the wiki? Suse and Ubuntu are there already

[graysky]

@enen92 - Honestly, building on Arch and Arch ARM is best accomplished using the PKGBUILD/files with makepkg.  Building by hand is just antiquated since the PKGBUILD will automatically handle all needed deps, give users a high degree of reproducible, and produce an Arch-native package for install/management via the distro package manager.  I might send a PR using the Arch native tools, but honestly, it would be just reiterating Arch native docs.

[graysky]

@enen92 - I took a crack at a guide per your suggestion: https://github.com/graysky2/xbmc/blob/ar...ME.Arch.md

I will review it/edit and create a PR once satisfied.

[enen92]

Great . As far as I remember, pkgbuild compiles from source and installs the package in the system. Hence it looks more geared towards users than Devs. Those build guides were made to help users compiling from source and ultimately contribute to the code base. They should start with checking out the code from the git repo.
Checking the pkgbuild from somewhere and hiding depends don't look exactly right. Can you explain how to make a pkgbuild file using the current depends and the local repo (if that's even possible)?

[graysky]

@enen92 - The PKGBUILD is a simple bash script that works together with another bash script called makepkg (both officially supported by the Distro).  Here is a link to the PKGBUILD: https://git.archlinux.org/svntogit/commu...kages/kodi

As you see, the source is defined in the source array and pulls the Kodi officially tagged release tarballs.  The makedepends and depends are not hidden, they are defined in their respective arrays in the PKGBUILD as well.

I could adjust the guide draft to point not to the official PKGBUILD (pulling your tagged stable release) but to the kodi-git PKGBUILD in the AUR (which I happen to maintain).  That PKGBUILD pulls the latest git.  Is that what you're asking for?

[enen92]

Not exactly as that will always be tied to a particular git ref. The idea is to clone the repo, modify as you wish locally and build your own version as many times as you want. Of course that if you don't modify anything you're basically building master...but that's not the end goal of the build guides.

[graysky]

Actually, the default option on a git package is to pull down the latest commit despite the fact that the PKGBUILD contains an older commit, so no worries there.  I guess I could modify the text to:
1) Point the git PKGBUILD.
2) Show how to change the source repo from the official one to a fork which presumably people modifying the source would do (ie fork their own copy and build from it).

Is that more aligned with the goals?

[enen92]

Actually, the default option on a git package is to pull down the latest commit despite the fact that the PKGBUILD contains an older commit, so no worries there.  I guess I could modify the text to:
1) Point the git PKGBUILD.
2) Show how to change the source repo from the official one to a fork which presumably people modifying the source would do (ie fork their own copy and build from it).

Is that more aligned with the goals?

That means users would have to commit the changes to a certain repo just for the sake of compiling their local copies. That's not really the goal of those docs. Isn't it possible to point pkgbuild to a local folder on the fs?

[graysky]

Actually, the default option on a git package is to pull down the latest commit despite the fact that the PKGBUILD contains an older commit, so no worries there.  I guess I could modify the text to:
1) Point the git PKGBUILD.
2) Show how to change the source repo from the official one to a fork which presumably people modifying the source would do (ie fork their own copy and build from it).

Is that more aligned with the goals?

That means users would have to commit the changes to a certain repo just for the sake of compiling their local copies. That's not really the goal of those docs. Isn't it possible to point pkgbuild to a local folder on the fs? 

Yes, it can be done.  Let me edit my file accordingly.  Will update when done.  Interested in your feedback.

[graysky]

@enen92 - OK, I think I delivered on what you pointed out.  Please review and comment: https://github.com/graysky2/xbmc/blob/ar...ME.Arch.md

EDIT: https://github.com/xbmc/xbmc/pull/16155