mcpp toolchain remove only takes the @ spelling, while its two sibling subcommands take either. Nothing signals that, so the natural attempt fails with an error that reads like the family name itself is wrong:
$ mcpp toolchain remove gcc 15 --target x86_64-linux-musl
error: invalid spec 'gcc'
$ mcpp toolchain remove gcc@15 --target x86_64-linux-musl # works (partial version resolves)
error: gcc@15 → x86_64-linux-musl is not installed
Reproduced on 0.0.107.
Cause
remove declares one positional; install and default each declare two (src/cli.cppm):
.subcommand(cl::App("install") // 365
.arg(cl::Arg("compiler")...)
.arg(cl::Arg("version")...) // ← second positional
.subcommand(cl::App("default") // 377
.arg(cl::Arg("spec").required())
.arg(cl::Arg("version")...) // ← second positional
.subcommand(cl::App("remove") // 385
.arg(cl::Arg("spec").help("<family>@<version>").required())
// no second positional
So gcc lands in spec alone and fails to parse. Both install and default carry a comment explaining that the two spellings are equivalent — remove looks like it was simply missed.
Fix
Add the same second positional to remove and feed it through the same spec join. The help text (<family>@<version>) should then match defaults <family>[@<version>] (version may be partial), since partial versions already resolve here.
Worth a small e2e asserting all three subcommands accept both spellings, so they cannot drift apart again.
mcpp toolchain removeonly takes the@spelling, while its two sibling subcommands take either. Nothing signals that, so the natural attempt fails with an error that reads like the family name itself is wrong:Reproduced on 0.0.107.
Cause
removedeclares one positional;installanddefaulteach declare two (src/cli.cppm):So
gcclands inspecalone and fails to parse. Bothinstallanddefaultcarry a comment explaining that the two spellings are equivalent —removelooks like it was simply missed.Fix
Add the same second positional to
removeand feed it through the same spec join. The help text (<family>@<version>) should then matchdefaults<family>[@<version>] (version may be partial), since partial versions already resolve here.Worth a small e2e asserting all three subcommands accept both spellings, so they cannot drift apart again.