feat: export OHOS_NDK_HOME to env by default

[richerfu]

This can help us optimize the user experience, ohrs and some community adaptations use OHOS_NDK_HOME by default.

[jschwe]

Could you sign-off your commit? (git commit --signoff).

Is there a reason ohrs and other apps use OHOS_NDK_HOME instead of the variables hvigor expects or sets?

[richerfu]

In fact, there is not. When I was doing related adaptation work in the early days, I did not find any documents related to the environment variables output by hvigor (and I don’t seem to see any now), so I referred to some community naming schemes of Android and used them. OHOS_NDK_HOME is used as an environment variable.

[jschwe]

Should OHOS_NDK_HOME point to the parent directory of native?

[jschwe]

Rebased and merged in #12

[richerfu]

Should OHOS_NDK_HOME point to the parent directory of native?

I think you are right and how about the following variable definition?

OHOS_HOME:
the root directory of the sdk, the tree should be like:

./
├── ets
├── js
├── native
├── previewer
└── toolchains

OHOS_NDK_HOME:
the sub-folder of OHOS_HOME named native.

./
├── NOTICE.txt
├── build
├── build-tools
├── compatible_config.json
├── llvm
├── nativeapi_syscap_config.json
├── ndk_system_capability.json
├── oh-uni-package.json
└── sysroot

If you agree, I will gradually replace it with the above definition in the future. @jschwe

[jschwe]

For the long-term I would suggest migrating to OHOS_SDK_NATIVE instead of OHOS_NDK_HOME, since that environment variable will be set by hvigor and is hence somewhat official. (I don't remember if it was merged in time for hvigor 5, or if it will need to wait for hvigor 5.1).

For the parent directory of native it seems there is no official variable name yet. Perhaps we should keep in mind that when developing for OpenHarmony (not HarmonyOS NEXT), DevEco Studio / hvigor require the parent directory to be the API level.
This may be useful for users that wish to compile the same application multiple times for different minimum API levels, just by switching the --product flag of hvigor.

./${OHOS_BASE_SDK_DIR}
|── 11
|── 12
  ├── ets
  ├── js
  ├── native
  ├── previewer
  └── toolchains

[richerfu]

OK, i got it.

OHOS_BASE_SDK_DIR: the root directory for SDK and the sub-folders should be api-version and so on.
OHOS_SDK_NATIVE: the currently using native folder with api-version.

there is another question that for newer DevEco Studio version it will provide more complex struct.

./${OHOS_BASE_SDK_DIR}
└── default
    ├── hms
    │   ├── ets
    │   ├── native
    │   ├── previewer
    │   └── toolchains
    ├── openharmony
    │   ├── ets
    │   ├── js
    │   ├── native
    │   ├── previewer
    │   └── toolchains
    └── sdk-pkg.json
└── HarmonyNext-Beta.2
    ├── hms
    │   ├── ets
    │   ├── native
    │   ├── previewer
    │   └── toolchains
    ├── openharmony
    │   ├── ets
    │   ├── js
    │   ├── native
    │   ├── previewer
    │   └── toolchains
    └── sdk-pkg.json

So i think we need to define a variable for the parent folder with native, it can help us to use toolchains simpler.

[jschwe]

there is another question that for newer DevEco Studio version it will provide more complex struct.

Actually it is different depending on if you use DevEco Studio to compile for OpenHarmony or for HarmonyOS NEXT.
When targeting HarmonyOS NEXT, then the base dir is called DEVECO_SDK_HOME and has the children default etc, like you wrote.
When targeting OpenHarmony, e.g. for the dayu-200 rk board, then hvigor expects the directory structure I wrote in my comment above and OHOS_BASE_SDK_DIR must be set.

This means we have two different environment variable names (OHOS_BASE_SDK_DIR and DEVECO_SDK_HOME), which hvigor reads and also two different directory layouts - depending on if the user is targeting OpenHarmony or HarmonyOS (For DevEco and hvigor 5).