Add a command to run bitbake <recipe>
#18
Conversation
deribaucourt
force-pushed
the
command-build-recipe
branch
11 times, most recently
from
904fc49
to
99970bd
Compare
deribaucourt
force-pushed
the
command-build-recipe
branch
2 times, most recently
from
2e5202d
to
9bde323
Compare
The UI directory should contain all sources related to User Interraction.
Even though the compilation watch where effective, changes to the package.json weren't updated when running the debugging configuration.
Previously, the language server had a dedicated channel in the Output window. Since the client will start getting more complex, it will also require to log messages. This commit adds a logger class that will handle logging to the Output window and the console. The Output channel name for the language server was renamed to start with "BitBake" to be easy to associate with the extension.
The client extension will become more complex, so it is better to start structuring the different features.
Add a class to store the bitbake configuration from the extension's
settings. Mostly copied from the BitBakeProjectScanner.
Now supports ${workspaceFolder} in the settings.
A bitbake type can now be declared in tasks.json. Currently, it executes a dummy shell which does not use the bitbake configuration. Next commits include that logic.
The need for managing an active workspace arose and will be completed in future developments to also contain devtool workspaces and saving the internal state.
Replace the dummy executor with the task provider. This allows us to execute the build command and show the output in the terminal view.
The output had poorly rendered new lines. It turns out that the VSCode terminal expects carriage returns to properly start new lines.
Passing the BUILDDIR as argument rather than using "cd" fixes some bitbake variables which make the compilation work.
The user may inject special characters in the settings paths. The function to sanitize the command was moved to the settings in order to be shared with the driver.
Build tasks now provide a "build spinner" in the status bar. Tasks are put in the build group if the bitbake task name contains "build". Ex: do_build While clean tasks are put in the clean group like: do_clean, do_cleansstate, do_cleanall
Bitbake has lots of different error messages, so we need to add problem matchers for them. This commit adds problem matchers for the most common errors. Currently, this doubles the messages of the bitbake parsing scanner. We'll have to select which messages to display in the future.
deribaucourt
force-pushed
the
command-build-recipe
branch
3 times, most recently
from
c9eba0f
to
a4b6bff
Compare
Use the VSCode workspace state to store the active recipes. This way they are saved between VSCode sessions.
This adds a new command to clean a recipe or an image. The task configuration produced some warnings which are fixed in this commit.
deribaucourt
force-pushed
the
command-build-recipe
branch
from
a5b2eda
to
83d0006
Compare
It is now possible to run the bitbake commands by right clicking on a file that has one of the bitbake extensions.
deribaucourt
force-pushed
the
command-build-recipe
branch
from
83d0006
to
7115551
Compare
deribaucourt
force-pushed
the
command-build-recipe
branch
from
c3b3fed
to
4e38165
Compare
| const chosenRecipe = await selectRecipe(bitbakeWorkspace, uri) | ||
| if (chosenRecipe !== undefined) { | ||
| logger.debug(`Command: build-recipe: ${chosenRecipe}`) | ||
| const task = new vscode.Task( |
There was a problem hiding this comment.
Apparently this constructor for Task is deprecated. The scope should be specified
There was a problem hiding this comment.
Indeed! strange that eslint doesn't report it? I'll merge as is for stability and fix this later
|
|
||
| import * as vscode from 'vscode' | ||
|
|
||
| export class OutputLogger { |
There was a problem hiding this comment.
Isn't something that could be implemented by an external library, same way the server is currently using winston?
There was a problem hiding this comment.
From my experience so far, the winston logger sometimes didn't work (e.g. analyzer.ts). But the connection.sendNotification() always works.
If we only care about logs then having our custom logger in this case is ok IMO. Do we want to have something ful-featured like winston?
There was a problem hiding this comment.
I am not saying we should keep winston, but I question having two different loggers plus having to maintain our own
I noticed we are using winston version 2.4.4, while the latest is 3.11.0. Maybe it could solve some issues.
There was a problem hiding this comment.
All the extensions I have seen use custom loggers (cmake, docker, ...) which maybe is not ideal!
I needed a different logger because it's great to have separate output channels for the language server and the extension (as a language client). We can address this later for sure!
No description provided.