I have CoreELEC building and have been modifying code by altering the source files that I found under the build.CoreELEC-Amlogic-ng.arm-20 directory, deleting the appropriate build_target file under the .stamps folder and rebuilding using DEVICE=Amlogic-ng make.
As I am starting to make more changes, this has become very cumbersome, changes are not tracked as the build.CoreELEC-Amlogic-ng.arm-20 folder is excluded from git, etc…
I take it altering code that you find in build folder isn’t the right way to do it, but that seems to be the only place that has source files in the repo I cloned. I’m broadly familiar with git, but haven’t really worked on projects this large before.
I have found that the linux code (for example) exists as another repo. I assume I should clone that and make changes there. Is this the right way? And if so, what do you need to do to get these changes built into the original CoreELEC repo I have building images?
TL;DR
What process is recommended to change code / develop CoreELEC code when the actual code seems to exists in different repos than the one used to build images?
I am no expert but I have cloned and built Visual Pinball on my Linux desktop. I only cared about the standalone version which was in a build folder. Since that project is setup to build for multiple platforms as well as the standalone version I assumed that was why the structure was that way.
It may be the same with CE since its made for multiple chipsets.
What do you mean the sources are not there? In GitHub, there’s only the one master branch visible for CE20 and CE21, and those should contain all the common and different code parts. For example take a look at the path projects/Amlogic-ce/devices.
You’ll want to create patch files to apply if you don’t want to copy-paste the same changes every time. Of course they may also need to be adjusted at times.
Exactly what I said, the repo GitHub - CoreELEC/CoreELEC: A lightweight OS for KODI doesn’t seem to actually contain the “actual” code. Just look at the changes - to me, it looks like (essentially) all that is ever done in that repo is bump packages numbers.
For example, the file I am currently looking at is amcsc.c. It lives in an entirely separate repo, GitHub - CoreELEC/linux-amlogic. I assume that when I built CoreELEC this was downloaded onto my computer, but like I said, it only appears to exists in the untracked build folder - why I was looking for a better method
Checkout the version you want of CoreELEC/CoreELEC repo, the packages in that refer to the other repo as you mention - with the commit id / version to pull down on build.
Checkout the repo you want to make a change in e.g. CoreELEC/linux-amlogic for the corresponding commit id and make your changes, then place a git diff back in the appropriate patches folder in CoreELEC/CoreELEC - fingers crossed there is not another diff already there and clashing!
I don’t think that is it. Having a look at the LibreELEC repo it also appears to be set up identically - no actual code and links to the actual code through packages from other repos. Doesn’t appear to be a CoreELEC specific approach to me now.
Now I guess the better question to ask would have been: For those unfamiliar with large “build systems”, dealing with packages, and having code split across different repos than the one it is built in, what workflow is recommended to effectively make and then build changes?
I have now got the suggested setup of cloning the other linux repo and creating patch files that I then place in the main CoreELEC/CoreELEC repo. While it is definitely a better approach than what I was doing before, it still feels somewhat cumbersome to me.
I think some degree of unwieldiness is unavoidable. I would also suggest trying to break things down into smaller components and trying to get them merged sooner. For example, if you fixed the erroneous conversion to BT.601, then you can submit a PR for that one. It’s also a good way to get feedback and avoid having to redo too much.