Hi Alex
On Fri, 2025-12-26 at 21:46 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> On Wed, 24 Dec 2025 at 16:08, Adrian Freihofer via
> lists.openembedded.org
> <[email protected]> wrote:
> > VSCode is started in the workspace folder where the .vscode
> > directory
> > is located. With the new bitbake-setup based build layout, this
> > starts
> > VSCode in the openembedded-core directory, which means only files
> > in
> > that layer are visible. This is not usable for most projects which
> > span multiple layers.
> ...
> > # Generate an initial configuration for VSCode and the yocto-
> > bitbake plugin.
> > -if command -v code > /dev/null && [ ! -d "$OEROOT/.vscode" ]; then
> > - oe-setup-vscode "$OEROOT" "$BUILDDIR"
>
> I'm not sure I understand how 'seeing multiple layers' worked before,
> or did it? If .vscode is placed into $OEROOT, then only $OEROOT is
> visible, e.g. only the former integrated poky repo, but not other
> layers.
>
> Otherwise I guess this should be held until we figure out the changes
> to bitbake-setup?
>
My goal is to support making bitbake-setup a first-class user
experience while still preserving the simple, good old way without it.
My understanding of the old way is:
git clone poky && cd poky
. oe-init-build-env
We (and many others) use a slightly more advanced but still static
directory structure based on this basic concept. The following example
is very close to what running bitbake-setup init twice (once for poky-
master and once for oe-nodistro-master) would create:
build
poky-master
conf
site.conf
bblayers.conf
templateconf.cfg
oe-nodistro-master
conf
site.conf
bblayers.conf
templateconf.cfg
bitbake
meta-foo
scripts
oe-setup-vscode
meta-yocto
openembedded-core
scripts
oe-buildenv-internal
oe-setup-vscode
oe-init-build-env
oe-init-build-env
This can be used like this:
git clone --recurse-submodules foo-project ... && cd foo-project
. oe-init-build-env build/poky-master
Switching to oe-nodistro-master is as simple as starting a new shell
and running:
. oe-init-build-env build/oe-nodistro-master
The oe-init-build-env in the top level is a slightly customized copy of
poky/oe-init-build-env. It can, for example, modify the PATH variable
to prioritize scripts found in meta-foo/scripts over scripts found in
openembedded-core/scripts. This allows overriding scripts like we have
it for all the bitbake-related files in layers.
The logic: Set up the build environment with PATH (so bitbake can be
found), OEROOT, and BUILDDIR, then run further scripts which use these
variables.
I hope this explains:
* How 'seeing multiple layers' worked before (my understanding)
* Why I ended up with calling init-build-env (respectively the old oe-
init-build-env) rather then calling separate scripts from bitbake-
setup:
- Keep it independent from bitbake-setup (at least for now)
- Benefit from bitbake-setup: It has to run before everything else
runs which is the right time for dropping a VSCode configuration.
- Support customizing the .vscode/settings.json for project specific
layers
I'm not against creating the VSCode configuration directly from
bitbake-setup. But I think it is more complicated than it looks like. I
also don't want to be the guy who polluted all the git repositories
whit editor specific code :-). OE-core is enough for now.
I hope this at least explains, why I ended up whit these patches.
Thank you.
Regards,
Adrian
> Alex
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#228571):
https://lists.openembedded.org/g/openembedded-core/message/228571
Mute This Topic: https://lists.openembedded.org/mt/116929993/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
