Sublime Forum

Build Systems

#21

[quote=“jps”]

[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.[/quote]

Just ran into this as well. The basic issue is that the default prompt “Build With:”, which the ctrl+shift+b binding opens, does not include variants and just entering the name of the variant in the command palette has a fairly high chance at times to find different command items since variant names are arbitrary. I can think of two ways to solve this:

  1. Rename the command palette entries for build variants from “Build (VARIANT): BUILD-SYSTEM NAME” to “Build With: BUILD-SYSTEM NAME (VARIANT)”

  2. When a build system is selected that has multiple variants, open another quick panel to select the variant. Kind of like Goto Definition.

  3. would be faster to select (only one prompt) while 2. makes the command palette less cluttered with all the variants and gives a clearer overview of the builds available. I think I prefer 1.

@farfromrefuge: I think you need to select the base build system with the variant first using the ctrl+shift+b, or explicitly specify the build sytem with the “build_system” argument.

command: build {"build_system": "Packages/User/pytest.sublime-build"}
0 Likes
#22

@jps specifying the build_system as “Packages/Titanium Build/Titanium.sublime-build” works. But it would nice to be able to specify it with only “Titanium” as i don’t where the user installed the package.
THanks

0 Likes
#23

@farfromrefuge: Doubt this is gonna happen since mutliple build systems can share the same name but exist at different locations, just like every other file for ST-extension except themes.

Just confirm that the user installs the package in the correct folder (“Titanium Build”) by explicitly instructing him to do so. If they use Package Control (which they should) it will always install to the same folder/archive name.

0 Likes
#24

@farfromrefuge: You shouldn’t need to specify a build system, and it works for me without specifying one.

Repro steps:

  • Clone github.com/farfromrefug/MakeTi.git into Packages
  • Edit Titanium.sublime-build, changing source.javascript to source.js
  • Open a .js file
  • Press super+shift+r: titaniumMostRecents is run

Running the build command with a variant argument (but no specified build system) will find all relevant build systems that have that variant, and run the build system if there’s only one option (as happens in the above case), or prompt if there are multiple build systems with that variant (NB., it looks like this scenario is broken in 3073, as selecting one will just prompt again)

0 Likes
#25

[quote=“FichteFoll”]

  1. Rename the command palette entries for build variants from “Build (VARIANT): BUILD-SYSTEM NAME” to “Build With: BUILD-SYSTEM NAME (VARIANT)”

Perhaps I’m missing something, but I can’t see what scenario this would improve?

For my own use, I have a build system variant called ‘Premake’, and when I want to run it, I open the Command Palette and enter Premake. Here, the wording of the item in the Command Palette isn’t an issue. It’d be great if you could go into a bit more detail with how you’re using it, so I can understand what’s going on.

Previously, the wording for variants in the command palette was “Build: Variant”, whereas now it’s “Build (Variant): (Build system)”. Unless you’ve got multiple build systems that share the same variants, there’s been almost no change to how variants are selected and run with the build system changes.

FWIW, there are a couple of factors that influenced the current wording:

*] The variant entry can’t start with “Build With”, otherwise it’ll appear intermingled in the list of available build systems when prompting the user to select a build system after hitting primary+b

  1. Having the variant name before the build system name helps the presentation in the command palette when there are multiple build systems with the same variant
    /*:m][/quote]
0 Likes
#26

First off, this is a new proposal and didn’t exist before the build systems change. It doesn’t make too much sense with how variants are currently made available, so I’ll give a few more details.

Basically, I kind of want to select a build variant as the “primary build”. I realize that this it is currently not designed for that, meaning that you either have to create a binding to always run a certain variant or to select it all the time. I could probably also define multiple very similar build systems, but it seems like a better idea to me to group relevant build options into the same main file as variants in case of special needs. This leads to the situation where I would like to run a certain variant more often than once and would like so select the variant as primary.

Is this the wrong idea and should I just create more build systems? Or is it a good idea to allow “primary selection” of build variants? If the latter is the case, how could variants be made available to be selected as the primary build without crippling the build selection in case there are many?

0 Likes
#27

Ok, understood, I just wanted to be sure that the current build system changes haven’t introduced any difficulties that I’m not aware of.

With regards to variants, I think having the primary+b working on a build system+variant combination is fundamentally the right way to go. It’d would imply that when selecting a build system, you’ll have a lot more options presented, because the list will be all build system+variant combinations, but the flip side is you can then easily select a ‘Run’ or ‘Unit Test’ variant without having to dedicate a key binding to each.

One of the reasons I didn’t go with that approach originally is because of occasional variants, such as ‘make clean’, where you’d never want to run them twice in a row, e.g., first you’d have to press cmd+shift+b, and enter clean, then the next time you want to build, you’d have to remember to press cmd+shift+b again and choose the original build system. I’m planning on getting around this by still leaving the variants in the Command Palette, so that you can choose to run a variant that way, and it won’t be remembered as the last choice.

It may be worthwhile adding an ‘occasional’ flag to variants, to indicate they should never show up in the primary+shift+b list.

0 Likes
#28

Great, sounds good to me.

By the way, while you’re here, I think I found a very weird interaction with view.run_command(‘insert’, …) and scrolling which I am absolutely clueless about. Maybe you could read the details at the github issue and confirm this issue or shed some light: github.com/wbond/package_contro … t-76654458 (and following comment) Example code included.

0 Likes
#29

Works ok for me: no matter how many times the command is run, the text is appended to the bottom of the buffer (unless the selection has been manually changed, of course), and the view is scrolled to the bottom.

If you want to discuss a repro in any more depth, please send me an email or start a new thread, rather than letting this one go off topic.

0 Likes
#30

[quote=“jps”]
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.[/quote]

You are correct, my issue was primary the multiple Build system resolved in 3073 and the change of the caption of variants.
With the last ST build, everything works pretty good again after changing my pre-populated caption.
Thanks.

IMHO, the caption of variants was better before, compare:

Build: MASTER PRODUCTION Build: MASTER TEST Build: 2.0 PRODUCTION Build: 2.0 TEST
with:

Build (MASTER PRODUCTION): Oracle_List Build (MASTER TEST): Oracle_List Build (2.0 PRODUCTION): Oracle_List Build (2.0 TEST): Oracle_List
I don’t care the Build system name as I’ve already selected it, so it’s just noise when reading.

In addition, using Command Palette has the drawback to show unrelated items, like when running Build With… :

Build With: A Build With: B Build (all with defaults) : Production

What about some kind a context argument to the show_overlay -> command_palette to only show entries related to a specific context like:
-build_variants
-build_with
-…
The context could added to the items in .sublime-commands file and be used by plugins to customize limit the content of the Command Palette.

0 Likes
#31

I think the Build command for the main build is missing from the Command Palette, or is it how it was designed ?
If I have a build file with a main M and 2 variants (V1 and V2), the result is:

Build With: MyBuild Build (V1): MyBuild Build (V2): MyBuild
In my mind, Build With was for selecting/changing the Builder, not to run it.
But it looks it used for both, am I correct ?

If I use the pre-populated Command Palette “Build (”, I have only the variants, not the main.
How can I show a list of both the main and the variants builders ?
If I use “Build : MyBuild”, I have unrelated items like “Build With: AnotherMyBuild”. And I couldn’t search the proposed items with the variant’s name (typing V2 to select it).

0 Likes
#32

at the moment i have following problem: i have a folder open in sublime, there is a makefile present in the folder, yet sublime does not suggest Make as a build system, but uses C++ sys everytime i try to compile

restarting sublime, reopening the folder as project and so on changes nothing on this behaviour

0 Likes
#33

@bizoo there are some more changes coming to how build systems and variants are run in 3074, so I’ll hold off on going into the rationale behind the build system setup in 3073.

btw, it’s worth noting that there’s no notion of a selected build system any more, just relevant build systems. The Command Palette will show all relevant build systems and their variants.

@valerij_: what’s the exact name, included the exact case, of your makefile? Please also confirm your OS, the version of Sublime Text that you’re running, and if there’s only one, or multiple, folders in the sidebar.

0 Likes
#34

OK, this my thoughts after quickly testing build 3074:

  • I like the new captions in Command Palette for Build System and variants.

  • FWIU, selecting and running build is 2 different command. The main menu “Build With…” item (no default keybinding ?) select the build system AND the variant and save it in the project (and run it). Next call to the Build command run this variant of the Build System. “Build With:” items in the Command Palette only run it. IMHO, works great this way.

  • My only complaint (sorry :blush:): I still have trouble to display a list of the variants of the current Build System:
    I tried a pre-populated Command Palette "Build With: - ", but this show the variants of ALL the Build System, not the currently selected.
    IMHO, it’s rather difficult to find a good solution using only pre-populated Command Palette, why not add a new command to display the current Build System (the main one) and all it’s variants, something like what you’ve done with “Build With…”:

"command": "build", "args": {"choose": true, "text": "V2.0"}

An argument for pre-populating the selection would be nice, this way you can filter the list (eg. " - " to display only variants, or " - TEST " to display only variants related to TEST).

Thanks for your works Jon.

0 Likes
#35

file name is all lowercase makefile
OS: Windows 7
Devbuild 3073
a single folder, added via grad and drop (screen recording here)

just installed the update, problem persists

0 Likes
#36

Make.sublime-build will only be picked up in the presence of a ‘Makefile’, and not a ‘makefile’. I’ll look at addressing this in the future.

0 Likes
#37

@jps thanks for the latest changes in 3074. really nice.
Now are we going to have a project setting to force the default build system? I kind of hate to have to select it again on every project opening / ST restart.

Thanks

0 Likes
#38

I’m totally lost with the new update :frowning:
all build systems are gone, build command says “no build system”, build with command says “no build system”, creating a new build system doesn’t change anything…how am I supposed to build now? the lessc plugin doesn’t seem to work anymore. do I have to compile my less files now manually from cmd??

0 Likes
#39

@doumer: if you remove the selector from the build system, it’ll appear as a candidate

0 Likes
#40

wohoo, it works, thanks a lot! sorry for my dumbness. :wink:

0 Likes