| Message ID | 20240213221846.109260-3-adrian.freihofer@siemens.com |
|---|---|
| State | New |
| Headers | show |
| Series | vscode: improve settings for new yocto plugin | expand |
On Tue, 13 Feb 2024 at 23:19, Adrian Freihofer <adrian.freihofer@gmail.com> wrote: > If more layers are used or a different folder structure is used the > build folder and the .vscode folder should probably be at a different > location, where the OEINIT variable is required. > One use case is a layer structure like this: > > my-top-dir <-- OEINIT > build <-- BUILDDIR (=BBPATH) > .vscode > settings.json > oe-init-build-env > my-layer > meta-oe > poky <-- OEROOT > oe-buildenv-internal > oe-setup-builddir I don't understand. When and how this situation would occur? Why would it be set this way? I really don't want to add more variables into core scripts for something that looks marginal at best. Alex
On Wed, 2024-02-14 at 07:37 +0100, Alexander Kanavin wrote: > On Tue, 13 Feb 2024 at 23:19, Adrian Freihofer > <adrian.freihofer@gmail.com> wrote: > > If more layers are used or a different folder structure is used the > > build folder and the .vscode folder should probably be at a > > different > > location, where the OEINIT variable is required. > > One use case is a layer structure like this: > > > > my-top-dir <-- OEINIT > > build <-- BUILDDIR (=BBPATH) > > .vscode > > settings.json > > oe-init-build-env > > my-layer > > meta-oe > > poky <-- OEROOT > > oe-buildenv-internal > > oe-setup-builddir > > I don't understand. When and how this situation would occur? Why > would > it be set this way? Probably always when working for a project which uses more than only poky itself. It's just one example for a directory structure where the build folder is not inside of the poky directory. The purpose of the OEINIT variable is to support templates which need to know where the folder with the oe-init-build-env script is. This folder is considered as the current working directory of the user's editor, IDE, terminal or what ever is used to work on the layers. Do you have a better proposal how I could generate a config file which is located in the directory where the user's editor is running? > > I really don't want to add more variables into core scripts for > something that looks marginal at best. I'm not sure if this patch here is more marginal than adding a conf- description.txt. The conf-description.txt could almost be considered a copy of the conf-notes.txt. I am not against the conf-description.txt. But to call my patch marginal in comparison seems a bit extreme to me. Adrian > Alex
On Wed, 14 Feb 2024 at 10:01, <adrian.freihofer@gmail.com> wrote: > > > One use case is a layer structure like this: > > > > > > my-top-dir <-- OEINIT > > > build <-- BUILDDIR (=BBPATH) > > > .vscode > > > settings.json > > > oe-init-build-env > > > my-layer > > > meta-oe > > > poky <-- OEROOT > > > oe-buildenv-internal > > > oe-setup-builddir > > > > I don't understand. When and how this situation would occur? Why > > would > > it be set this way? > > Probably always when working for a project which uses more than only > poky itself. It's just one example for a directory structure where the > build folder is not inside of the poky directory. build folder not inside poky is fine. What I don't understand as how and why oe-init-build-env appears outside of poky/scripts (or openembedded-core/scripts) to begin with. What would place it there? Would it be different to the canonical verison in poky/scripts? Why not use the canonical version? That bit of explanation is missing in your patchset. > The purpose of the OEINIT variable is to support templates which need > to know where the folder with the oe-init-build-env script is. This > folder is considered as the current working directory of the user's > editor, IDE, terminal or what ever is used to work on the layers. > > Do you have a better proposal how I could generate a config file which > is located in the directory where the user's editor is running? In the above case you could place it in BUILDDIR/../ ? Also, why would oe-init-build-env have to take care of generating it? If something is calling that script to set things up, that something might as well write out the vscode-specific items? > I'm not sure if this patch here is more marginal than adding a conf- > description.txt. The conf-description.txt could almost be considered a > copy of the conf-notes.txt. I am not against the conf-description.txt. > But to call my patch marginal in comparison seems a bit extreme to me. description is a one-liner explanation, notes is a multi-paragraph usage text. There's already a prior agreement that both are needed, but there's no such agreement for OEINIT. Alex
diff --git a/oe-init-build-env b/oe-init-build-env index 38333ab8582..14917a425ee 100755 --- a/oe-init-build-env +++ b/oe-init-build-env @@ -41,12 +41,18 @@ if [ -z "$OEROOT" ]; then fi unset THIS_SCRIPT +# OEINIT is where the oe-init-build-env script is located. +# If this script is provided by a different layer OEINIT != OEROOT. +OEINIT="$OEROOT" + +export OEINIT export OEROOT . "$OEROOT"/scripts/oe-buildenv-internal && TEMPLATECONF="$TEMPLATECONF" "$OEROOT"/scripts/oe-setup-builddir || { unset OEROOT return 1 } +unset OEINIT unset OEROOT [ -z "$BUILDDIR" ] || cd "$BUILDDIR" diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir index 1b5dc55743e..dfd9acbb2cf 100755 --- a/scripts/oe-setup-builddir +++ b/scripts/oe-setup-builddir @@ -93,7 +93,8 @@ EOM # bitbake without the init script after the first run. # ##COREBASE## is deprecated as its meaning was inconsistent, but continue # to replace it for compatibility. - sed -e "s|##OEROOT##|$OEROOT|g" \ + sed -e "s|##OEINIT##|$OEINIT|g" \ + -e "s|##OEROOT##|$OEROOT|g" \ -e "s|##COREBASE##|$OEROOT|g" \ "$OECORELAYERCONF" > "$BUILDDIR/conf/bblayers.conf" SHOWYPDOC=yes
Introduce a new OEINIT variable which can be used by templates. OEINIT refers to the directory where the oe-init-build-env script is. The template engine needs this information to generate the .vscode directory and the settings.json file. For the most basic use case where only poky is used, the build folder and the .vscode folder can be generated in poky. That means OEINIT = OEROOT --> poky. If more layers are used or a different folder structure is used the build folder and the .vscode folder should probably be at a different location, where the OEINIT variable is required. One use case is a layer structure like this: my-top-dir <-- OEINIT build <-- BUILDDIR (=BBPATH) .vscode settings.json oe-init-build-env my-layer meta-oe poky <-- OEROOT oe-buildenv-internal oe-setup-builddir Having this infrastructure in the core allows for example overriding the oe-init-build-env script in my-top-dir like this: OEINIT=$(dirname "$THIS_SCRIPT") OEINIT=$(readlink -f "$OEINIT") OEROOT="$OEINIT/poky" Many different folder structures should be supported by this concept. Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> --- oe-init-build-env | 6 ++++++ scripts/oe-setup-builddir | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-)