[Feature Request]: support actual vscode tasks as pre/post build/flash tasks. (VSC-1805)

[cnf]

Is your feature request related to a problem? Please describe.
right now, the pre/post build/flash and custom task entries are shell commands that get executed.

Describe the solution you'd like
I would like to be able to trigger actual vscode tasks. This gives a lot more control over where the output goes, matching errors, conditional chaining, etc.

Describe alternatives you've considered
Right now, i just have shell commands, but it lacks the flexibility of vs tasks.

Additional context
Supporting vstasks also allows you to use other extensions tasks, so you can hook into cmake etc tasks. This would make this a lot more powerfull

[brianignacio5]

I'm not sure what do you mean of vscode tasks ? These pre/post build flash task are programmatically the same as vscode task ( we even use vscode.Task) and executeTask functions.

Could you provide me an idea of what is it that you are trying to achieve? You want to use tasks defined in tasks.json to be able to be used in pre post tasks?

[Smity]

Not sure if this is exactly what OP is talking about, but it would be really nice to be able to use tasks.json to control the behaviour of the build/flash/monitor/etc tasks, rather than having them hardcoded in the extension as they currently are. If that's not what's being asked, I can create a new issue.

[brianignacio5]

Shouldn't that be already available as tasks.json ? I mean any vscode user can just run a task from tasks.json even without extension.

I fail to see the advantage or use case of this. Maybe you would like more flexibility to control the extension commands build flash and monitor but I'm not sure what is it that you would like to control.

[Smity]

No, we can't use tasks.json to change the behaviour of the build, flash, or monitor tasks. They aren't even defined there, evidenced by the fact that the extension doesn't generate a tasks.json file for new projects. I've tried making one and changing the behaviour of those tasks, but nothing I do has any effect on the extension.

This feature would be great for me and my team because we have certian flashing requirements that aren't available from IDF. For example, we build our application with Secure Boot enabled, but we don't set security fuses on our development boards. We've modified the bootloader so it won't set fuses, either. One reason we did this was so we could flash our development code with the Stub Loader, but IDF disables the Stub Loader if Secure Boot is enabled. Flashing without the Stub Loader wastes a considerable amount of time in development. Since we can't modify the flash task using tasks.json, we have to use a pre-flash task which modifies build/flasher_args.json; but by the time the pre-flash task runs, the arguments are already loaded, so if a modification was needed, the pre-flash task has to return an error so we can restart the flash task. It's all quite hacky and would operate much smoother if we could modify the flash task to call something other than idf.py.

Sure, we could write a seperate vscode task in tasks.json and call it from the Command Palette, but that wouldn't be automatic like the extension's flash task. It wouldn't save source files before building, and it wouldn't run when we use the combined Build, Flash, and Monitor task.

I could give you more examples if you want, and I'm sure there are others who could offer even more.

[brianignacio5]

So basically you would like to customize the flash task arguments.

The build task is customizable because you can use idf.cmakeCompilerArgs for CMake configure step and idf.ninjaArgs for ninja compile step. Flashing with JTAG is configurable with idf.jtagFlashCommandExtraArgs for OpenOCD flash command but the UART flashing is not because we are using the build/flasher_args.json for esptool.py. We could make so you can have a idf.esptoolFlashArgs that would override build/flasher_args.json.

How does this sound for you?

[Smity]

It's more than just changing the arguments, though. We also have an extra data partition that we have to flash using a separate script or command; we have a script that sets the manufacturing date in efuse; and we have another (post-build) script that signs the bootloader thrice, since multiple signing keys aren't supported by sdkconfig options. All of these things happen conditionally depending on the state of the device we're working with. The conditional behavior we need isn't available from the extension because arguments are loaded before the tasks run (pre and post tasks can't affect the arguments). In order to achieve the conditional behavior, I wrote a Python script that makes calls to various IDF tools. My script connects to the device first, then determines what to do based on what fuses are set, whether the PSRAM is present, whether the data partition is present, etc. Even without conditional behaviour, the script is still much faster than the default IDF tasks because it only needs to connect to the device once, whereas the default tasks would have to reconnect around four times.

Customizing task arguments definitely is a step in the right direction, but still doesn't give us full control over the Build, Flash, and Monitor tasks. IDF (including the VSCode extension) is really good at most things, but it will never be able to do everything. What I really want is the ability to redirect/redefine the default extension tasks to anything, so I can get functionality that isn't available from IDF. Using tasks.json seems like a good way to do that, since most VSCode users are already familiar with that system.

[cnf]

I'm not sure what do you mean of vscode tasks ? These pre/post build flash task are programmatically the same as vscode task ( we even use vscode.Task) and executeTask functions.

Could you provide me an idea of what is it that you are trying to achieve? You want to use tasks defined in tasks.json to be able to be used in pre post tasks?

yes, exactly that. Use tasks defined in tasks.json as pre/post tasks. This allows for reuse of actions, and gives more power over how those are run. you can have groups, or error catchers/parsers, you can make them quiet, unless there is a certain error. you get control over presentation, finer control over environment, output behaviour, run behaviour, etc, you basically get all of this

(sorry if my reply is a bit late/unstructured, i am on vacation atm)