Cleanup VSCode tasks.json
Categories
(Firefox Build System :: General, task)
Tracking
(firefox72 fixed)
Tracking | Status | |
---|---|---|
firefox72 | --- | fixed |
People
(Reporter: tcampbell, Assigned: tcampbell)
References
(Blocks 1 open bug)
Details
Attachments
(5 files)
The config files for vscode seem to have bit rotted a bit. I have some patches to clean this up and make a few more things on windows work out of the box.
Assignee | ||
Comment 1•5 years ago
|
||
These options default to outer contexts so we don't need to repeat ourselves.
We were already setting the top level values anyways.
Assignee | ||
Comment 2•5 years ago
|
||
In the migration to the 2.0 format we seem to have dropped the base mach
command from a few of the defined tasks.
Depends on D52081
Assignee | ||
Comment 3•5 years ago
|
||
The ${workspaceRoot} variable was deprecated when multi-folder workspaces
were added to VSCode.
Depends on D52082
Assignee | ||
Comment 4•5 years ago
|
||
Current versions of mozilla-build ignore the current working directory so
explicitly 'cd' to workspace before running mach. Due to path mangling issues
copying from vscode -> powershell -> msys-bash, I used a PowerShell fragment
to translate the path.
Depends on D52083
I don't think anyone from the build list has much familiarity with this file. It might make more sense to get it reviewed by another vscode user. I'll volunteer jya if you don't have anyone else in mind.
Updated•5 years ago
|
Assignee | ||
Comment 6•5 years ago
|
||
As people who last touched the .vscode/tasks.json file, do either of you have objections to these changes and/or can someone rubber-stamp them? I've been testing on Win10+mozilla-build and Ubuntu linux.
The final patch should be the only one that might be controversial. It does expect that powershell is around, but that doesn't seem unreasonable for now. The change makes it work out-of-the-box with mozilla-build (which currently defaults to user home directory).
The ${relativeFile} stuff is still busted on windows platforms because the msys invocation mangles path. I won't try to tackle it now, but might be fixable with windows-specific args override using the same substitutions.
Updated•5 years ago
|
Can't rubberstamp as I'm not savvy enough; thank you for doing this though.
Pushed by tcampbell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/530c4ab772a6 Avoid duplication in .vscode/tasks.json r=jya https://hg.mozilla.org/integration/autoland/rev/57a4794a87f2 Fix argument lists in .vscode/tasks.json r=jya https://hg.mozilla.org/integration/autoland/rev/27ab68adb7d0 Use workspaceFolder in .vscode/tasks.json r=jya https://hg.mozilla.org/integration/autoland/rev/519ad74e9d7b Use full path to mach in .vscode/tasks.json on Windows r=jya
Comment 9•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/530c4ab772a6
https://hg.mozilla.org/mozilla-central/rev/57a4794a87f2
https://hg.mozilla.org/mozilla-central/rev/27ab68adb7d0
https://hg.mozilla.org/mozilla-central/rev/519ad74e9d7b
Assignee | ||
Comment 10•5 years ago
|
||
It seems the version of windows path mangling I landed does not quite work. Our build is breaks if I call 'C:\path\to\mach' vs 'c:\path\to\mach'. There is a very complicated dance of msys and windows binaries that get run through the build, so the simplest fix is to tweak the command to be cd C:\path\to; mach
so that the path normalization works the same as if you opened prompt manually.
Updated•5 years ago
|
Assignee | ||
Comment 11•5 years ago
|
||
The build is quite fragile if the path to mach is not precisely
formatted. Work around this by cd-ing to the appropriate directory and
then calling 'mach' with a relative path. This mimics a normal user
workflow in mozilla-build.
Comment 12•5 years ago
|
||
Pushed by tcampbell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4e3a2ac7a81d Change directory before running mach in .vscode/tasks.json on Windows. r=jya
Comment 13•5 years ago
|
||
bugherder |
Description
•