diff mbox series

[1/4] bitbake-setup: update vscode workspace always

Message ID 20260406202430.1856836-2-adrian.freihofer@siemens.com
State New
Headers show
Series bitbake-setup: extra-remotes support for contrib push mirrors | expand

Commit Message

AdrianF April 6, 2026, 8:24 p.m. UTC
From: Adrian Freihofer <adrian.freihofer@siemens.com>

Update the vscode workspace file with the current build directory, even
if the configuration in the registry has not changed. This allows to
keep the workspace file up to date when the build directory is changed
manually.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
 bin/bitbake-setup | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Alexander Kanavin April 7, 2026, 6:30 p.m. UTC | #1
On Mon, 6 Apr 2026 at 22:24, Adrian Freihofer via
lists.openembedded.org
<adrian.freihofer=siemens.com@lists.openembedded.org> wrote:
>      logger.plain("\nConfiguration in {} has not changed.".format(setupdir))
> +    if update:
> +        workspace_file = os.path.join(setupdir, "bitbake.code-workspace")
> +        if os.path.exists(workspace_file):
> +            bitbake_builddir = os.path.join(setupdir, "build")
> +            configure_vscode(setupdir, layerdir, bitbake_builddir, os.path.join(bitbake_builddir, "init-build-env"))

Will this do the update quietly or inform the user that vscode
workspace is being synced with local changes even though no
configuration updates have been detected?

Perhaps this should be its own command rather, something like
'update-vscode-workspace' ?

Alex
Adrian Freihofer April 7, 2026, 7:58 p.m. UTC | #2
On Tue, 2026-04-07 at 20:30 +0200, Alexander Kanavin via
lists.openembedded.org wrote:
> On Mon, 6 Apr 2026 at 22:24, Adrian Freihofer via
> lists.openembedded.org
> <adrian.freihofer=siemens.com@lists.openembedded.org> wrote:
> >      logger.plain("\nConfiguration in {} has not
> > changed.".format(setupdir))
> > +    if update:
> > +        workspace_file = os.path.join(setupdir, "bitbake.code-
> > workspace")
> > +        if os.path.exists(workspace_file):
> > +            bitbake_builddir = os.path.join(setupdir, "build")
> > +            configure_vscode(setupdir, layerdir, bitbake_builddir,
> > os.path.join(bitbake_builddir, "init-build-env"))
> 
> Will this do the update quietly or inform the user that vscode
> workspace is being synced with local changes even though no
> configuration updates have been detected?

The configure_vscode function preserves user-customized VSCode
configurations and it enforces essential settings required for proper
functionality. That means, executing configure_vscode should not harm
and hence it should be fine to just run it always (when "which code" is
true).

Having this as a separate command looks like more complicated for the
user. Expecting that the user always does something like

  bitbake-setup update
  bitbake-setup update-vscode-workspace

would be inconvenient. Most probably the user would just not run the
second command and end up with an inconsistent environment which can be
very annoying.

Or do you mean a separate command in addition to calling the
configure_vscode function in init and update? That would then lead to
the question when the user should run bitbake-setup update-vscode-
workspace. After init? After update? Or just if update does nothing but
the VSCode configuration needs an update?
Having only bitbake-setup update to update what ever might needs an
update, looks at least simple to me. But I agree, a separate command
could work as well.

Maybe this patch is not very important if bitbake-setup itself does not
change anymore. Might be that I thought this should be improved when
working on bitbake-setup itself, which is a very special use case.

Thanks for the quick feedback
Adrian

> 
> Perhaps this should be its own command rather, something like
> 'update-vscode-workspace' ?
> 
> Alex
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#19351):
> https://lists.openembedded.org/g/bitbake-devel/message/19351
> Mute This Topic: https://lists.openembedded.org/mt/118697281/4454582
> Group Owner: bitbake-devel+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/bitbake-devel/unsub [adrian.freihofer@gmail.com
> ]
> -=-=-=-=-=-=-=-=-=-=-=-
Alexander Kanavin April 8, 2026, 12:22 p.m. UTC | #3
On Tue, 7 Apr 2026 at 21:58, <adrian.freihofer@gmail.com> wrote:

> Maybe this patch is not very important if bitbake-setup itself does not
> change anymore. Might be that I thought this should be improved when
> working on bitbake-setup itself, which is a very special use case.

What I would like to understand is this: what kind of local changes
require re-generating the vscode workspace (when otherwise there are
no changes in bitbake-setup configuration). Presumably the user does
'something' that causes the workspace to go out of sync, what is it,
can you provide examples? Can we write the workspace in a more
'universal' way such that it doesn't happen?

Alex
diff mbox series

Patch

diff --git a/bin/bitbake-setup b/bin/bitbake-setup
index c006a059c..5a3394092 100755
--- a/bin/bitbake-setup
+++ b/bin/bitbake-setup
@@ -956,6 +956,11 @@  def build_status(top_dir, settings, args, d, update=False):
         return
 
     logger.plain("\nConfiguration in {} has not changed.".format(setupdir))
+    if update:
+        workspace_file = os.path.join(setupdir, "bitbake.code-workspace")
+        if os.path.exists(workspace_file):
+            bitbake_builddir = os.path.join(setupdir, "build")
+            configure_vscode(setupdir, layerdir, bitbake_builddir, os.path.join(bitbake_builddir, "init-build-env"))
 
 def build_update(top_dir, settings, args, d):
     build_status(top_dir, settings, args, d, update=True)