HarmonyOS/OpenHarmony Port

[Jack253-png]

Description

SDL support for harmonyos

Existing Issue(s)

#9837

[Jack253-png]

@slouken Request for review

[Jack253-png]

@madebr @sezero Request for review

[madebr]

Can you please rebase on top of current master and remove all commits which you did not author?

git fetch https://github.com/libsdl-org/SDL main
git rebase -i FETCH_HEAD
<remove all commits which you did not author. In vim, "dd" removes the current line, "<ESC>:wq" saves and exits)>
git push git@github.com:Jack253-png/SDL HEAD:OpenMinecraft-Dev -f

[madebr]

Seeing you implemented vulkan support, does SDL_gpu work? Do the SDL_gpu_examples work?

[Jack253-png]

Seeing you implemented vulkan support, does SDL_gpu work? Do the SDL_gpu_examples work?

I will test later, because I don't have test platform, I need to find other people to do this.

[Jack253-png]

@madebr Finish

[madebr]

Nice work you did here!

Do all unit tests work? (ctest tests with a dummy video driver).
Does running test/testautomation --video dummy succeed?
Does running test/testautomation --video ohos work?
Does test/testsprite --renderer opengl work?
Does test/testsprite --renderer vulkan work?
Does test/testsprite --renderer gpu work?
Does test/testfile work?
Does test/testfilesystem work?

Do you also intend to add support for other subsystems?
I looked a bit through the sparse English documentation, and it looks like ohos also has camera support.

[madebr]

Please undo these comments, and just make sure to add [sdl-ci-filter harmony] in the message of your last commit. This script will then only build haiku and openharmony.

[Jack253-png]

Nice work you did here!

Do all unit tests work? (ctest tests with a dummy video driver).
Does running test/testautomation --video dummy succeed?
Does running test/testautomation --video ohos work?
Does test/testsprite --renderer opengl work?
Does test/testsprite --renderer vulkan work?
Does test/testsprite --renderer gpu work?
Does test/testfile work?
Does test/testfilesystem work?

Do you also intend to add support for other subsystems?
I looked a bit through the sparse English documentation, and it looks like ohos also has camera support.

I need to buy a test platform, I may hang this PR for about 2 weeks, and it is able to create vulkan/egl surface for now (I borrowed another developer's PC and runs the emulator, and it's unavailable for now)

[Jack253-png]

Nice work you did here!

Do all unit tests work? (ctest tests with a dummy video driver).
Does running test/testautomation --video dummy succeed?
Does running test/testautomation --video ohos work?
Does test/testsprite --renderer opengl work?
Does test/testsprite --renderer vulkan work?
Does test/testsprite --renderer gpu work?
Does test/testfile work?
Does test/testfilesystem work?

Do you also intend to add support for other subsystems?
I looked a bit through the sparse English documentation, and it looks like ohos also has camera support.

I will try to implement the locale, audio subsystem, and locale api implementation is inside the ets part.

[madebr]

It would also be useful to write some documentation for the docs directory.

Since openharmony is a relatively new os, documentation about how to package a SDL app would be useful. I hope it's not a mess like Android ;)

[Jack253-png]

It would also be useful to write some documentation for the docs directory.

Since openharmony is a relatively new os, documentation about how to package a SDL app would be useful. I hope it's not a mess like Android ;)

I have already written a sample harmony/openharmony app at https://github.com/OpenMinecraft-Dev/sdl-ohos-shell, I will try to put it inside

[Jack253-png]

Does it work? I changed the commit message

[sezero]

Does it work? I changed the commit message

Hmph. It still seems to run all the workflows. @madebr: Is the filtering correct?

[madebr]

Does it work? I changed the commit message

Hmph. It still seems to run all the workflows. @madebr: Is the filtering correct?

I'm using ${{ github.event.head_commit.message }} to get the commit message.
It looks like this works for the run in Jack's fork, but does not for this PR.

[Jack253-png]

Does it work? I changed the commit message

Hmph. It still seems to run all the workflows. @madebr: Is the filtering correct?

I'm using ${{ github.event.head_commit.message }} to get the commit message.
It looks like this works for the run in Jack's fork, but does not for this PR.

Do you find the problem? Why it works in my repo?

[madebr]

On pushes, github.event is a push object, which has a .head_commit.message` property.

On pull requests, github.event is a pull_request (synchronize) object. This objects does not have .head_commit.message property. Through github.event.pull_request.commits_url, we can find out the commit message.
This url returns paged data with a maximum of 100 items. We need the last item, so it'd require to iterate the list.
The event has github.event.pull_request.merge_commit_sha, but does not return the sha of the head commit of the pr. Doing something like git log -n -1 HEAD~1 does not reliably return the correct commit (remember, we test merge commits in pull requests, not the actual head commit)

[Jack253-png]

On pushes, github.event is a push object, which has a .head_commit.message` property.

On pull requests, github.event is a pull_request (synchronize) object. This objects does not have .head_commit.message property. Through github.event.pull_request.commits_url, we can find out the commit message.
This url returns paged data with a maximum of 100 items. We need the last item, so it'd require to iterate the list.
The event has github.event.pull_request.merge_commit_sha, but does not return the sha of the head commit of the pr. Doing something like git log -n -1 HEAD~1 does not reliably return the correct commit (remember, we test merge commits in pull requests, not the actual head commit)

It is an existing bug in SDL GitHub workflow?!

[madebr]

It is an existing bug in SDL GitHub workflow?!

Yes and no.
Yes because parsing commit messages do not work.
No because pull requests creators cannot sneakily disable a workflow.

So yes, the problem was already present.

[sezero]

. No because pull requests creators cannot sneakily disable a workflow.

So yes, the problem was already present.

Actually that's a good thing and not a problem. A patch causing problems
elsewhere would go undetected otherwise.