Add font-fallback on OpenHarmony and fix several compilation issues

[jschwe]

Adds a fallback font and fixes several compilation issues when compiling for OpenHarmony.

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• These changes fix #___ (GitHub issue number if applicable)

• There are tests for these changes OR
• These changes do not require tests because ___

[jschwe]

Perhaps pay special attention to this file. It's based on an earlier version of android/font_list.rs, which received some updates in the recent days.
My current approach was to just hardcode one version of the HarmonyOS Sans font family available on ohos devices and update the list of fallback families for codepoints.
There are quite a few HarmonyOS_Sans_*.ttf files available on ohos devices. I chose one with the largest filesize, and that seemed to work well in practice.

There is also a fontconfig.json available, which could be parsed (for an example see https://github.com/jschwe/ohos-fontconfig/blob/main/src/lib.rs)

[mrobinson]

Instead of a new port do you mind creating a custom path in the existing servoshell? I think it's better that all platforms have their own servoshell implementation rather than a custom build target, which makes the mach scripts much more complicated.

[jschwe]

Instead of a new port do you mind creating a custom path in the existing servoshell

The native code for OpenHarmony is loaded as a dynamic library into a TypeScript / Javascript app, and the OH port is very similar to the android port, and doesn't share much (perhaps even any) code with servoshell at the moment.
I believe currently there is no way to specify in a Cargo.toml file that a lib target should be a cdylib on target a, and an rlib on all other targets, is there? Would you be fine with unconditionally building servoshell as both an rlib and a cdylib on all targets? I could imagine that this would incur some compile time regressions if LTO is enabled.

[jschwe]

@mrobinson How about merging the OH app into the same package as the android app instead?

[mrobinson]

@mrobinson How about merging the OH app into the same package as the android app instead?

My goal is to merge the Android app into servoshell as well since they are both effectively "servoshell" but for different platforms. The hope is that they can eventually share more code.

he native code for OpenHarmony is loaded as a dynamic library into a TypeScript / Javascript app, and the OH port is very similar to the android port, and doesn't share much (perhaps even any) code with servoshell at the moment.
I believe currently there is no way to specify in a Cargo.toml file that a lib target should be a cdylib on target a, and an rlib on all other targets, is there? Would you be fine with unconditionally building servoshell as both an rlib and a cdylib on all targets? I could imagine that this would incur some compile time regressions if LTO is enabled.

The OpenHarmony shared library built here isn't useful with the Servo repository. This is different from the Android application, because you can actually build the entire application with the Servo repository. I don't see too much of an advantage to keep this code in the repository since the CI isn't testing it and there is no way to run it without the other part. Can you submit just the parts that fix the build for Open Harmony and maintain the part that builds a servo shared object with the rest of your application?

[jschwe]

The OpenHarmony shared library built here isn't useful with the Servo repository. This is different from the Android application, because you can actually build the entire application with the Servo repository

My hope was to open-source/upstream everything required to build servo for OpenHarmony - I just didn't want to make one huge pull request and instead split things up into multiple smaller PRs (with CI planned to be one of the last ones, as I wouldn't have time before RustNL).
The actual OpenHarmony app code (slightly outdated by now, but not by much) can be viewed here. I was considering putting that part into the support folder, next to the android folder.

Can you submit just the parts that fix the build for Open Harmony and maintain the part that builds a servo shared object with the rest of your application?

Sure, for now I will drop the skeleton app commit. For the future I would still hope that I can upstream the full demo app. Just let me know if you would accept it (in general), and if yes, if you want everything to be in one big PR, with CI and everything, or if splitting things up would be preferable.

[mrobinson]

This seems fine though there is one small thing I noticed:

[mrobinson]

This comment should likely be updated?

[jschwe]

Thanks! Adjusted this comment while rebasing.