OpenWrt development in VSCode for dummies

For Developers
1

Hi!

I've just started doing some development using VSCode. I know my way around with VSCode as i use it for my job. I have almost no experience with "make" and C-tools. I think i've managed to create a few small PRs, but this took quite some time and persistance. I think it would benefit OpenWrt to make starting with development easier.

I did some tinkering and ended up with a VSCode workspace file which:

  • Allows for editing multiple OpenWrt GIT repositories (packages, luci, etc.) in a single editor.
  • Allows for running make package commands for the current open Makefile of a package.
  • Allows for running a task by choosing from a predefined set.
  • It's using the buildbot CI-container devcontainer.

I think some possible improvements:

  • to aid in correct creating feature-branches
  • It would allow to create some scripts to "squash multiple commits" for instance.

Is this something which is usable?

{
	"folders": [
		{
			"path": "."
		},
		{
			"path": "./feeds/packages"
		},
		{
			"path": "./feeds/luci"
		},
	],
	"extensions": {
		"recommendations": [
			"ms-vscode.cpptools",
			"plorefice.devicetree",
			"augustocdias.tasks-shell-input"
		]
	},
	"tasks": {
		"version": "2.0.0",
		"tasks": [
			{
				"label": "update and install all OpenWrt feeds",
				"type": "shell",
				"command": "./scripts/feeds update -a && ./scripts/feeds install -a",
				"group": "none",
				"icon": {
					"id": "refresh"
				},
				"problemMatcher": [],
				"detail": "Update and install all feeds"
			},
			{
				"label": "override OpenWrt feeds",
				"type": "shell",
				"command": "cp  --interactive ./feeds.conf.default ./feeds.conf && code ./feeds.conf",
				"group": "none",
				"icon": {
					"id": "edit"
				},
				"problemMatcher": [],
				"detail": "Customize the default feeds"
			},
			{
				"label": "make defconfig",
				"type": "shell",
				"command": "make defconfig",
				"group": "none",
				"icon": {
					"id": "star-empty"
				},
				"problemMatcher": [],
				"detail": "Make defconfig"
			},
			{
				"label": "make menuconfig",
				"type": "shell",
				"command": "make menuconfig",
				"group": "none",
				"icon": {
					"id": "star-empty"
				},
				"problemMatcher": [],
				"detail": "Make menuconfig"
			},
			{
				"label": "make -j4",
				"type": "shell",
				"command": "make -j4",
				"group": "none",
				"icon": {
					"id": "star-empty"
				},
				"problemMatcher": [],
				"detail": "Make -j4"
			},
			{
				"label": "make package of open Makefile",
				"type": "shell",
				"command": "make package/${input:packageID}/clean && make package/${input:packageID}/compile",
				"icon": {
					"id": "run"
				},
				"problemMatcher": []
			}
		],
		"inputs": [
			{ 
				"id": "packageID", 
				"type": "command", 
				"command": "shellCommand.execute",
				"args": {
                	"command": "grep -F -m 1 'PKG_NAME:=' ${file} | cut -d= -f2",
					"useSingleResult": true,
            	}		
			}
		]
	},
	"settings": {
		"git.alwaysSignOff": true,
        "git.allowForcePush": true,
        "git.confirmForcePush": true,
        "git.autofetch": "all",
        "git.autorefresh": true,
        "git.branchProtection": ["master","main"],
        "git.branchPrefix": "feature_",
        "git.branchProtectionPrompt": "alwaysCommitToNewBranch",
        "git.branchWhitespaceChar": "_",
        "git.branchValidationRegex": "feature_.+",
	},
}
3 Likes
2

Interesting idea. I use vscode for development but just use the terminal to build and such. However, I do see one issue at a glance ..

this is not optimal for all systems and should be parameterized instead. I'm not sure how you would absorb it but i use -j $(nproc) or something to that effect. IMO even the option to specify the number would be better the hard coding the -j4.

Good work

1 Like
3

Big thanks for that. I have been playing around with the source as well and also use VSCode.

I guess the main developers just use the commandline and vim (or emacs). :sweat_smile:

A single workspace is a good start to bring all those repos together. Unfortunately you can't checkin that file, because of separate repositories.
Well, you could make one mono repo with that file and then have the repos as subtrees. But then you don't need the workspace file anymore, because it's a single repo / folder. :sweat_smile:

Also having VSCode extensions setup properly would really help. Recommendations plus settings. For make, for C syntax, for perl, shell, bash, python, some other scripts in obscure languages, Github actions, Github pull requests, yaml, json, markdown, kconfig files,...
Plus editorconfig for proper formatting according to the standard.

Add to that a git hook to lint staged files before pushing / commiting. And to check the commit message format.
None of this is there, to which I'm basically used to from the projects I worked on in the past.

And then for Windows users like me either the Devcontainer (not sure if I like the buildbot one, it might not be optimized), or scripts for local developments with docker / podman.

Then there is the question, why are those even separate repositories? Is that a legacy thing? Because according to their rules they don't give limited access, either full or nothing, for people in the project. So access can't be the reason.
From my limited understanding of their processes (and I dug a lot in the wiki and code), it just adds overhead to branch off releases in five (or more?) separate repositories.
And to manage the issues and PRs, both in handling replies as well as replicating things.

To me it feels like a relic of a long ago past and I'd like to elevate the processes into this century. Or at least the last one.

And not for the sake of changing things, but because it would make the project more approachable to new developers, tinkerers, people with limited coding experience.
Just look at how much effort it is currently to fix a simple bug in a package like vim. There was a change of name for the default config file. There have been two PRs over the last one or two years, neither of them merged yet.

There should be a linter that tells you "hey, increase the package version when you change files" or a Github action. And not a reviewer telling you to, wasting their time and yours, because you didn't read the five different wiki pages about contributing.

I hope I didn't go too far off topic. :grimacing:
Having this workspace file is a great step in the right direction.

1 Like