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
variants 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:
"file_regex": "^(..[^:\n]*):([0-9]+):?([0-9]+)?:? (.*)$",
"syntax": "Packages/Makefile/Make Output.sublime-syntax",
"keyfiles": ["Makefile", "makefile"],
"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:
"shell_cmd": "dotnet build",
"shell_cmd": "dotnet clean"
"shell_cmd": "dotnet run"
"name": "Run Interactive",
"shell_cmd": "dotnet run",
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.