On Sat, 27 Dec 2025 at 13:06, <[email protected]> wrote: > 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
Poky is no longer being updated, so this old way is gone and we don't need to worry about it. What still exists is checking out the separate repositories it was made of, usually into the same directory, but not always, together with any additional layers or other repositories needed in a given build. So you need to know where that top directory is, and I would rather avoid guessing that from oe-init-build-env, or oe-setup-vscode, and instead pass it in explicitly as a command line parameter, which means running oe-setup-vscode from bitbake-setup directly. > 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. Sadly the formatting/indentation in the directory list above was lost, so I can't quite make sense of the above. > 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. What I am proposing is this: 1. oe-setup-vscode does not try to guess things, or deduce things from $PATH or other environment variables. It takes everything needed to create vscode-specific files on its command line, as parameters. That includes where bitbake is, if vscode has to know that, and where build environment script is as well (e.g. the full path with a name). 2. How about rewriting oe-setup-vscode in python? Does it have to be shell? 3. bitbake-setup runs oe-setup-vscode directly, passing in all the needed parameters (it knows all of them) 4. standard oe-init-build-env from oe-core either does not run oe-setup-vscode at all anymore, or perhaps there could be some minimally useful setup it could still create, but I can't see how you would deduce the top dir with all the layers and the build dir easily and correctly in the general case. What it does now (passing $OEROOT, e.g. just oe-core location, to oe-setup-vscode and have vscode config created there) is not really useful (as you have explained), or is it? Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#228578): https://lists.openembedded.org/g/openembedded-core/message/228578 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]] -=-=-=-=-=-=-=-=-=-=-=-
