Only those licenses that are explicitly mention in the SPDX headers in the
repository are allowed to have license text files present. That means, that in
the LICENSE directory we can only have licenses for meta-data files and not
licenses for packages that this meta-data is used to build.

Signed-off-by: Robert Drab <robert.drab@huawei.com>

openharmony-standard-3.0: Fix missing runtime dependencies

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

libwms_client.z.so library was not installed on the target in OpenHarmony 3.0
causing QA issue and rightly so, as it is a bug.

Signed-off-by: Robert Drab <robert.drab@huawei.com>

Update source repositories to v3.0.1

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

This updates the OpenHarmony source repositories to version 3.0.1.

Only the patch for third_party/icu needed some rework and the removal of
compiler option '-Wno-error=implicit-float-conversion' for gcc.

This also set OPENHARMONY_VERSION_FULL to 3.0.1 the openharmony-3.0
distro override.

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

Various changes in preparation for integration with meta-oniro-core

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

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

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

This allows using java-tools.inc, and thus openharmony-standard,
hapsigner-native and packing-tool-native recipes with any distro configuration.
These recipes should only be used for OpenHarmony enabled distro configurations
anyway.

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

This enables the special OpenHarmony patches version of the gn tool for use with
any distro configuration which enables the "openharmony" in its DISTROOVERRIDES.

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

This allows building OpenHarmony compatible linux-yocto kernel using any distro
configuration which enables "openharmony" in its DISTROOVERRIDES.

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

This allows building OpenHarmony compatible linux-libc-headers using any distro
configuration which enables "openharmony" in its DISTROOVERRIDES.

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

This allows building OpenHarmony compatible musl using any distro configuration
which enables "openharmony" in its DISTROOVERRIDES.

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

This can be used for openharmony specific but distro-neutral overrides instead
of oniro-openharmony-linux.

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

This makes it easier to use of meta-openharmony in projects that does not use
oniro-openharmony-linux distro configuration.

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

We will be using flex-native and bison-native recipes instead from now on.

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

OpenHarmony 3.1 introduced another script which copies directly from
/usr/include/FlexLexer.h path, so we need to fix that as well in order
to not depend on host OS flex package.

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

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

Graphic stack bringup

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

Signed-off-by: Robert Drab <robert.drab@huawei.com>

Signed-off-by: Robert Drab <robert.drab@huawei.com>

In OpenHarmony 3.1 there is a gralloc implementation for a HiHope board which
is generic enough to be used with qemu virtio gpu.

Signed-off-by: Robert Drab <robert.drab@huawei.com>

Add MUSL_LDSO_PATHS distro variable

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

This change adds a post do_install() function that checks if all
subfloders copied from system/lib/module are set in the distro variable
MUSL_LDSO_PATHS and thus are part of the ld-musl-${MUSL_LDSO_ARCH}.path
file.

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

With this change, the OpenHarmomy lib paths are now added to
/etc/ld-musl-${MUSL_LDSO_ARCH}.path based on the content of the distro
variable MUSL_LDSO_PATHS.

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

This variable holds the system library folders used by OpenHarmony. It
will be used to generate the file /etc/ld-musl-${MUSL_LDSO_ARCH}.path.
It will also be used to do a sanity check and verify that all
/lib/module/* subfolders are parts of this musl ldso file.

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

Update OpenHarmony source repositories to v3.1.1

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

This change adds the variable OPENHARMONY_VERSION_FULL to the distro
configuration file. Its default value is set to OPENHARMONY_VERSION.

The idea is to keep the openharmony-standard recipe version number to
OPENHARMONY_VERSION (i.e. Major.minor) and have the variable
OPENHARMONY_VERSION_FULL indicating the patch version.

With the update of the OpenHarmony source repositories to v3.1.1, the
variable OPENHARMONY_VERSION_FULL is set to "3.1.1", through a new
DISTROOVERRIDES entry.

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

This adds /usr/lib/module/* subfolders to lib search path so OpenHarmony
components are able to find libraries they need.

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

I don't have a valid explanation for that but it turns out that fetching
3.0 repositories first then 3.1.1 ones leads to bitbake fetch failures.
Starting by fetching 3.1.1 then 3.0 repositories works better.

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

This updates the OpenHarmony source repositories to 3.1.1 version. This
also fixes a few  patches that now apply to 3.1.1 source trees.

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

openharmony-standard: Component packaging and systemd integration

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

This is initial work on splitting up OpenHarmony 3.1 components into individual
packages, and integrating the services of these as systemd services.

It is not complete, as we are shifting focus to OpenHarmony 3.0(.1) for now.

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

CI: Test toolchain and bundle images against OHOS codebase

Closes #6 and oniro#191

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

Update README.md and cosmetic changes

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

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>

Although not covered by the official OpenHarmony documentation, the ruby
interpreter and cpio tool is used during build.

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

Fetch OpenHarmony OS codebase release tarballs and test
oniro-openharmony-toolchain and oniro-openharmony-bundle against these.

In order to save CI resources, only MR pipelines run these new jobs
automatically.  For normal branch pipelines, the job are set to manual, so
developer can choose to run them as needed.

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