iOS build system

[yaroslavyaroslav]

• I'm the package's author and/or maintainer.
• I have have read the docs.
• I have tagged a release with a semver version number.
• My package repo has a description and a README describing what it's for and how to use it.
• My package doesn't add context menu entries. *
• My package doesn't add key bindings. **
• Any commands are available via the command palette.
• Preferences and keybindings (if any) are listed in the menu and the command palette, and open in split view.
• If my package is a syntax it doesn't also add a color scheme. ***
• If my package is a syntax it is named after the language it supports (without suffixes like "syntax" or "highlighting").
• I use .gitattributes to exclude files from the package: images, test files, sublime-project/workspace.

It's iOS sublime-build system with the first class of Sublime text support, like

• warnings/errors patterns matching within output log
• panel for presenting such warnings separately from the log itself (it could be very messy there)
• not hangs on a huge (around 100k lines) output of a xcodebuild

There are no packages for this tasks in PC yet.

[packagecontrol-bot]

Automated testing result: WARNING

Repo link: iOS build system
Results help

Packages added:
  - iOS build system

Processing package "iOS build system"
  - WARNING: The binding ['ctrl+c'] is also defined in default bindings but is masked with a 'context'
    - File: Default.sublime-keymap

[packagecontrol-bot]

Automated testing result: WARNING

Repo link: iOS build system
Results help

Packages added:
  - iOS build system

Processing package "iOS build system"
  - WARNING: The binding ['ctrl+c'] is also defined in default bindings but is masked with a 'context'
    - File: Default.sublime-keymap

[braver]

It's in a deep WIP state. So far a few golden paths are working.

I'm not sure we can review the package for addition in this state. If you're looking for testers or feedback, I would propose going onto the forums and discord if you're not there already.

[yaroslavyaroslav]

@braver oh, I see. It's actually not true already. Although the plugin has things to do and has not all options that I wish it had, it's quite stable and usable already.

So I'll delete this hint when I'll come to my laptop today.

[yaroslavyaroslav]

@braver Here I am with an update: I've deleted that controversial note that you've mention before. And added few utility things to the project from PC perspective (like release notes and gitattibutes)

And let me clarify your concern about actual quality of this plugin. It does a very few things so far, just one of them are really useful from my perspective — a path to build, install and run in iOS Simulator iOS project completely within ST. And it does that pretty stable at the time being, it also reflects and handles all build errors if any and provide a user an ability to cancel the building process while it's proceeding by a conditional hotkey (ctrl+c).

I believe that these few things are really important from iOS developer perspective, as I found myself really annoyed being needed to constantly switching back and forth between Xcode and ST during my everyday development.

I wish to add there a lot more flexibility in future, but so far I thinks an iOS folks would appreciate exact this, an ability to effortless build, install and run their project from within ST.

[braver]

Thanks for the information. It all looks very well thought out, and I can definitely see how this would be useful 👍🏻

[braver]

... only thing I can come up with is that a user might have re-mapped cancel_build and their preferred binding won't work for your package. You could document the key binding in the readme at minimum, or expose it in a menu entry. Just so it's discoverable for users without going into your codebase. You can do that after we ship this though, but something to consider.

[yaroslavyaroslav]

Yeah, definitely worth it, so I'll add this to 1.1.0 shortly.