Sublime Forum

Build Systems

#1

I’d like to make Build System selection a little more usable.

Currently, you select the active build system for the window via the menu, then Primary+B will run that build system. There is the option of Automatic selection of build systems, but probably in the majority of cases this isn’t able to do the right thing. Primary+Shift+B currently runs the current build system with the ‘run’ variant as a parameter.

What I’m thinking instead:

Primary+B will run the last used build system. If the last used build system isn’t relevant, or if there is no last used build system, then it prompts for a build system.

Prompting for a build system will involve showing the Command Palette pre-populated with all Relevant Build Systems.

Relevant Build Systems are determined in a similar way to the current ‘Automatic’ option: Any build system with a matching selector will be shown (e.g., Python.sublime.build if the current file is using the Python syntax definition), as will any build system with a matching keyfile (e.g., Make.sublime-build if there’s a Makefile in the current directory), as will any any build system that has neither a keyfile nor selector.

For example, if you’re editing a C++ file, and there’s a Makefile in the current directory, then pressing Primary+B will initially give you this list of options:

Build: Make
Build: Make Clean
Build: C++ Compile Single File
Build: C++ Compile and Run Single File

After selecting one, pressing Primary+B will rerun the same Build System without asking.

If the user has selected ‘Build: C++ Compile Single File’, and then starts editing a Python file, the next time Primary+B is pressed the dialog will popup again, as the last used build system is no longer in the relevant list.

Primary+Shift+B would be remapped to build but always show the popup, to ease the scenario of frequently swapping between two build systems.

This should help with the issue introduced in 3066, where having a Makefile in the current directory will make ‘Automatic’ always run that Makefile, even if you’d rather just use whatever build system is relevant to the current file.

Thoughts?

3 Likes

Build system screwed after upgrade
Dev Build 3072
Intelligent build system switching
#2

Your proposition looks good, but please keep in mind the following things:

Build Systems can be defined globally or in the project file.
And each Build System may define some variants.
This can lead to a lot of options.

Currently when using Automatic Build System, Build Systems from project file take precedence over the global ones.
I almost exclusively use custom Build System with custom exec command tailored for my use, and I set it in the project file to be sure it is the one that is used for the matching selector.

Please keep this behaviour as is either by default or via an option in the Build System definition from project (something like “override_default”:True) to always use this Build System and not opening the selection list if not absolutely necessary.

On the other hand, I like a way to always open the selection list for the variants of a specific Build System, when you have/want to choose a target for your build with no obvious choice. My proposal was to define a Build System without a main “cmd”, only variants “cmd”. In this case, ST open a selection list containing only the variants of the Build System.
In the context of your proposal, the selection list could show the main Build System (using a new “name” tag that already exists in variants) and after selecting it, a second list with the variants.

As your selection list will probably be managed by ST (following a build command), please keep in mind that people (mainly developer of plugins) sometimes don’t want it so keep a way (an argument of build command ?) to not display it.

Hope I was clear and thanks for reading.


github.com/bizoo/OracleSQL/blob … le_exec.py

1 Like

#3

I like it. That way I can have a build system for the project that matches on text, source (so everything) but still quickly opt to run the Python file I am currently editing in the same project by pressing ctrl+shift+b.

[quote]
I almost exclusively use custom Build System with custom exec command tailored for my use, and I set it in the project file to be sure it is the one that is used for the matching selector.[/quote]

You are supposed to override the default build systems in the “Packages” folder in that case, like PackageResourceViewer promotes and can also be seen on sublimetext.com/docs/3/packages.html

  • assuming this is global. Otherwise you specify it as a project build system in which case it will override anyway.

The exception is if you want to extend the default build system e.g. by a test runner, in which case you can choose to override the default and provide it as a variant or create another build system.

0 Likes

#4

[quote=“FichteFoll”]You are supposed to override the default build systems in the “Packages” folder in that case, like PackageResourceViewer promotes and can also be seen on sublimetext.com/docs/3/packages.html

  • assuming this is global. Otherwise you specify it as a project build system in which case it will override anyway.[/quote]

Exactly, I almost always use a project build system, and I don’t want to be asked if I want to use it or another build like the default one.
If I have a project build system, I want to always use it (by default or by an additional argument in the project build system, don’t care).

0 Likes

#5

Simplify, simplify, simplify.

Primary+B - Use the most recent build system, or the one for the matching file type if none has been used yet.
Shift+Primary+B - Show the menu of all the available build systems, regardless of what file type you’re sitting in.

And, if I may:

Ctrl+Primary+B - Display the build window. There’s no reason why this can’t be a simple keystroke.

0 Likes

#6

This is doable currently:

{ "keys": "ctrl+super+b"], "command": "show_panel", "args": {"panel": "output.exec"} },
0 Likes

#7

The available build systems are restricted by the file type already because those with a not matching selector are unavailable. If a build system specifies a selector it should be respected for that reason (or adjusted if it’s not general enough).

I much prefer the current proposal from jps over yours because it is more practical than this overly simplified version.

0 Likes

#8

Your project defines several build choices, (A), (B), and ©. My projects involve several languages, but perhaps no matter what file I’m currently visiting, my build is still ‘make build’, or ‘run simulation’, or ‘create webpages’, or whatever.

No matter what file I’m visiting in my project, I may still want the build choice to be (A) and only (A). Or, I may choose to want it to be (B) or ©. I shouldn’t have to switch to a different file to get (B) or ©. My point is, forget the file type and obey the project options.

0 Likes

#9

[quote]This is doable currently:

{ "keys": "ctrl+super+b"], "command": "show_panel", "args": {"panel": "output.exec"} },

[/quote]

Yup. And it would be nice if it were built-in. That’s all I’m saying.

0 Likes

#10

an option to select (multiple) targets when running make

atm i am using modified github.com/UNOwen/SublimeMakefileTargets bound to [CTRL][F7] but an propper built-in solution would be better

0 Likes

#11

I work in different languages each day, and is a little slow to use a menu for switching between build systems.

I suggest to automatically detect, based on the extension of the current file, which build system to use. Also, sublime may log what were the last successfully used build systems, and make our work easier.

0 Likes

#12

I just updated to the newest dev build 3072 and I like the new build menu.

However I am missing a way to build variants of the current build system. Currently I have to search for them in the big command palette.
May I suggest something like:
CTRL-SHIFT-B - Show all valid build systems. (Current behaviour)
CTRL-B - Build using last build system (if still valid). (Current behaviour)
CTRL-ALT-SHIFT-B - Show variants of last build system (like CTRL-B, but show the variants instead of running the primary build system)
CTRL-ALT-B - Build using last build variant of last build system (if still valid)

Basically my setup is that I have listed project specific build system in the ${project].sublime-project file, and as variants I have listed several ways to run unit tests on the build product.
So it would be really nice if there was an easy way to select among the build variants, and perhaps even a way to run the latest executed build variant.

Best Regards
/Bjarke Freund-Hansen

0 Likes

#13

[quote=“bjarkefh”]I just updated to the newest dev build 3072 and I like the new build menu.

However I am missing a way to build variants of the current build system. Currently I have to search for them in the big command palette.
May I suggest something like:
CTRL-SHIFT-B - Show all valid build systems. (Current behaviour)
CTRL-B - Build using last build system (if still valid). (Current behaviour)
CTRL-ALT-SHIFT-B - Show variants of last build system (like CTRL-B, but show the variants instead of running the primary build system)
CTRL-ALT-B - Build using last build variant of last build system (if still valid)

Basically my setup is that I have listed project specific build system in the ${project].sublime-project file, and as variants I have listed several ways to run unit tests on the build product.
So it would be really nice if there was an easy way to select among the build variants, and perhaps even a way to run the latest executed build variant.

Best Regards
/Bjarke Freund-Hansen[/quote]

+1000
The current behavior totally broke my workflow :frowning:
I have this kind of build file:

[code]{
“target”: “oracle_exec”,
“selector”: “source.plsql.oracle”,
“variants”:

	{
		"name": "DEPLOYMENT",
		"dsn": "DEPLOY/DEPLOY@DEPLOYMENT"
	},
	{
		"name": "TEST",
		"dsn": "TEST/TEST@TEST"
	}
]

}[/code]
I have a keybinding to select the variant:

{ "keys": "ctrl+alt+shift+b"], "command": "show_overlay", "args": {"overlay": "command_palette", "text": "Build: "} }

Before the command panel showed:

Build : DEPLOYMENT Build : TEST
Now:

Build (DEPLOYMENT): Oracle_list Build (TEST): Oracle_list
and a lot of other entry (Build: New Build System, …) unnecessary in this context.

0 Likes

#14

In addition the new behavior for selecting build is unusable if a project use more than one build system:
If you have a project that define 2 different build system, one for .js and one for .java files (using selector of course).
As the last selected build system is saved in the project workspace (and only one, not one per selector), each time you hit F7 after changing from a .js to a .java file (and vice versa) you have to select again which build to use.

Before, as the build system defined in the project take precedence over the others, the build system from the project was always called correctly.
Is it possible (as I already asked before) to have a flag in the project build systems to tell ST to use only these ones and not asking.

0 Likes

#15

Hmm, nice approach. But how do I run the different variants now?

Until now I did CTRL+SHIFT+P “cmake” to run the cmake-variant
CTRL+B to run cmake --build as “make” variant (or default)
CTRL+SHIFT+B run the run-variant

I’d like to run CMake via CTRL+P, Have a easy (max 2 keys) build shortcut and another short run shortcut.
Can I see the commands somewhere to make my own keybindings?

0 Likes

#16

[quote=“bizoo”]
Before the command panel showed:

Build : DEPLOYMENT Build : TEST
Now:

Build (DEPLOYMENT): Oracle_list Build (TEST): Oracle_list
and a lot of other entry (Build: New Build System, …) unnecessary in this context.[/quote]

Can you expand a bit on why this is problematic? As far as I can tell, the workflow is identical, e.g., to run the ‘DEPLOYMENT’ variant, you open the command palette and enter deployment.

With regards to the other issue of switching between .js and .java files with multiple matching build systems, that should be resolved in the next dev build.

EDIT: It looks to me that what’s causing you grief is that when opening the Command Palette "Build: " pre-populated, you are now getting more entries than just the variants. If you change the key binding to pre-populate the Command Palette with “Build (” instead, then you’ll have a list of only the variants.

0 Likes

#17

Hey Jon,

This bug is present in the latest dev build and has been so at least since 3065 (I never used the Build Systems functionality prior to that, so not sure if it was occurring before then) but now’s probably a good time to raise it, while you’re looking at reworking the Build Systems.

The bug is simply a text misalignment issue on my display; best illustrated with a picture: *(http://i.imgur.com/poI930n.png)

Worth noting that the text within normal (ctrl+`) console renders just fine - this issue is only occurring within the build console.

Relevant system info:

  • MacBook Pro (Retina, 15-inch, Late 2013)
  • OS X Yosemite 10.10.2
  • NVIDIA GeForce GT 750M 2048 MB
  • 15.4-inch (2880 x 1800)*
0 Likes

#18

I have a big problem with the latest dev build: My custom build system does not appear anymore :s
i pushed the all package so that you can see: github.com/farfromrefug/MakeTi
I don’t see why it does not appear when editing a js file.

Can we force the build system on a per project basis?

Thanks

0 Likes

#19

@farfromrefuge, you should be using “source.js” rather than “source.javascript”. You can confirm this with the show_scope_name command (cmd+option+p on OSX, ctrl+alt+shift+p on Windows and Linux).

This is one of the changes that has tripped a few people up with the revised Build System selection: previously the “selector” was advisory, and was only used by the ‘Automatic’ build system, so it wasn’t a huge issue if it was wrong. However with the changes, if any selector is present, then the build system won’t be available at all unless it matches.

For anyone with a build system that isn’t showing up, the first step to working out what’s going on is to remove the “selector” key from your build system entirely: that will make it show up in any context (assuming no “keyfile” is set).

0 Likes

#20

[quote=“jps”]@farfromrefuge, you should be using “source.js” rather than “source.javascript”. You can confirm this with the show_scope_name command (cmd+option+p on OSX, ctrl+alt+shift+p on Windows and Linux).

This is one of the changes that has tripped a few people up with the revised Build System selection: previously the “selector” was advisory, and was only used by the ‘Automatic’ build system, so it wasn’t a huge issue if it was wrong. However with the changes, if any selector is present, then the build system won’t be available at all unless it matches.

For anyone with a build system that isn’t showing up, the first step to working out what’s going on is to remove the “selector” key from your build system entirely: that will make it show up in any context (assuming no “keyfile” is set).[/quote]

Amazing! you saved my day :smiley:
Now to the next one:
If you look at github.com/farfromrefug/MakeTi/ … ult%20(OSX.sublime-keymap you can see keymaps to trigger build system variants.
With the latest dev build the variant are not found.
For example i get “No Build System with variant Titanium History” with the keymap { “keys”: “super+shift+r”], “command”: “build”, “args”: {“variant”: “Titanium History”}
Should i change something?

Thanks

0 Likes