If you really need to build your code with 20 or 30 possible permutations, I doubt you’re going to be able to come up with a way to trigger that without being prompted somewhere to choose which of the 30 is the one you want to use right now.
Personally, if I had that sort of situation I would make a single build system with variant
s in it, since likely the only thing that’s changing is the command line and most everything else is the same. Then a Build With
will prompt you for the one to use, and it will keep using that one until you tell it to pick another one by using Build With
again.
Alternately you could have a custom target
using a plugin that prompts you for build variables before it executes the build without too much effort. Arguably, being prompted for every build is way more disruptive than just picking it once from the menu or the variant panel though.
I have videos on all of those topics, which I’m not going to link here for your stated reasons above. In any case, I would agree with @rwols that what you want is some sort of extra external build tool to make your life better overall.
Any time switching from one project to another requires you to rewrite a sublime-build
file, that’s a signal that you’re probably thinking about things the wrong way. The instructions on how to build and run any particular project or file should be stored with that project and not as a configuration in your editor.
For this example, presume the use of make
as a tool (which is just one of many). For any particular project, you create a control file that tells make
exactly what steps to take, in what order, to compile, build, and/or run your code, as well as any other things you need.
For every project you create one, and then you just need a single sublime-build
that knows how to interface with that tool:
{
"shell_cmd": "make",
"file_regex": "^(..[^:\n]*):([0-9]+):?([0-9]+)?:? (.*)$",
"working_dir": "${folder:${project_path:${file_path}}}",
"selector": "source.makefile",
"syntax": "Packages/Makefile/Make Output.sublime-syntax",
"keyfiles": ["Makefile", "makefile"],
"variants":
[
{
"name": "Clean",
"shell_cmd": "make clean"
}
]
}
So, by default it invokes make
, which finds the control file and does what it needs to do, and you can optionally get it to trigger a clean
. One single build, works for every project. And as an added benefit, your code projects also contain the instructions needed to build them, so if you share them with someone else there’s no mystery.
Or as another example, for dotnet
related programs I use this build:
{
"working_dir": "${folder:${project_path:${file_path}}}",
"selector": "source.cs",
"variants":
[
{
"name": "Build",
"shell_cmd": "dotnet build",
"word_wrap": false,
"quiet": true,
},
{
"name": "Clean",
"shell_cmd": "dotnet clean"
},
{
"name": "Run",
"shell_cmd": "dotnet run"
},
{
"name": "Run Interactive",
"shell_cmd": "dotnet run",
"target": "terminus_exec"
}
],
}
So, no matter what dotnet
project I’m in, this one single configured build works. I can just compile, clean up artifacts, build and then run, and even run interactively.