Kristijonas Čiulčinskas authored 2 years ago and Kristijonas Čiulčinskas committed 2 years ago

Signed-off-by: Kristijonas Ciulcinskas <kristijonas.ciulcinskas@huawei.com>

Kristijonas Čiulčinskas authored 2 years ago and Kristijonas Čiulčinskas committed 2 years ago

Signed-off-by: Kristijonas Ciulcinskas <kristijonas.ciulcinskas@huawei.com>

Kristijonas Čiulčinskas authored 2 years ago and Kristijonas Čiulčinskas committed 2 years ago

Signed-off-by: Kristijonas Ciulcinskas <kristijonas.ciulcinskas@huawei.com>

An upstream patch (oe-core) doesn't apply cleanly on the musl version
openharmony is using. Refresh to fix the associated build warnings.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

.gitlab: Add bug reporting template

Closes #37

See merge request eclipse/oniro-core/meta-openharmony!43

Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>

Change default OPENHARMONY_VERSION from 3.1 to 3.0

Closes #34

See merge request eclipse/oniro-core/meta-openharmony!42

A bit of cleanup and comments

Closes #30

See merge request eclipse/oniro-core/meta-openharmony!35

With current plan for OpenHarmony compatibility being focused on OpenHarmony
3.0.1, it makes most sense to have that as default version instead of 3.1(.1).

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This makes the bundle and toolchain images codebase match the source
used to build openharmony-standard v3.0 and v3.1, which are 3.0.1 and
3.1.1 respectively.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

This commit adds a patch that replaces calls to NAPI_CALL() with
NAPI_CALL_BOOL() on function returning a boolean. It applies on
//base/miscservices/pasteboard for OpenHarmony 3.1.1 code base. Even
though this pasteboard repository is not used by openharmony-standard
builds, the patch is needed for bundle and toolchain test jobs.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

This reverts commit 7400fb56.

This change is not needed anymore as it turns out that the error it was
supposed to fix only appeared on my local builds. The error simply
disappeared after a fresh full rebuild.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

Improve documentation for inclusion into Oniro

See merge request eclipse/oniro-core/meta-openharmony!39

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This is less ambiguous and aligns with the wording used in Oniro
documentation.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

By changing from MarkDown to RestructuredText format, we make it
easier to include in Sphinx documentation.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

CI: Attempt to throttle load caused by builds better

Closes #33

See merge request eclipse/oniro-core/meta-openharmony!38

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This pulls in latest oniro kirkstone HEAD, with patching of ninja so it can set
maximum load average based on MAXLOAD_NINJA variable.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This introduces support for new variable to be set by gitlab-runner.

It should be set to the load average that parallel builds should try to not go
above.  Build tools such as make and ninja is expected to not spawn no jobs
if/when load average is higher than this number.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This introduces support for new variable to be set by gitlab-runner.

It should be set to the max number of parallel jobs to be spawned. It will be
applied to both the number of concurrent bitbake threads/tasks and the number of
parallel jobs in each make/cmake/meson based bitbake task though. So take
care...

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This will make make and ninja builds also respect the value set by
$CI_ONIRO_NUM_CPU variable, and apply a sane default using the nproc shell
command.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Prepare for integration into meta-oniro-core

Closes #10 and #25

See merge request eclipse/oniro-core/meta-openharmony!36

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

We cannot even parse the recipes without meta-java, as we use java.bbclass.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This updates oniro layer to latest version, and all shared dependent layers to
the corresponding version.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This should be dropped once meta-openharmony is upgraded to a musl libc
version that includes qsort_r() function.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This will skip the recipe if openharmony is not enabled in DISTRO_FEATURES,
if TOOLCHAIN is not clang or if RUNTIME is not llvm.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

By using weak assignment for the java preferred providers, we avoid setting
java preferred provider variables if they are already set.
We should be fine with any valid setting.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This ensures libfts.a static library file is built, even if distro has
generally disabled static libraries.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

With this, the use of openharmony.inc will not change things unless
the `openharmony` distro feature is enabled.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

By moving more of the configuration into openharmony.inc, it becomes
easier to add OpenHarmony support to other distros.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Instead of hardcoding an `openharmony` override, this introduce an
`openharmony` distro feature which (when enabled) will add a
`df-openharmony` override.

The `openharmony` distro feature will also gate the `openharmony-3.0`
and `openharmony-3.1` overrides, so they are only active when `openharmony`
is enabled.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>