Building Your Projects

Fire and Water are designed to be light-weight and “get out of your way”, and one of the parts where this shines through is when you build. Compiling your project is a frequent task in your day-to-day work, and an essential part of any development environment.

You usually start a build by either hitting ⌘B / Ctrl+B (to just build) or ⌘R / Ctrl+R (to build, and then run), and when you do, the build system goes off to do its thing in the background, but aside from that, nothing much changes. There’s no modal dialog telling you the IDE is building, and the IDE does not lock up or get in your way. After all, building is something that happens passively and once a build is fired off, there isn't much you can do about it (although actually, that’s not quite true, more on that later on), so the IDE might as well just let you keep focusing on your code.

Building

So as Fire or Water go off to build, focus stays on the code editor (or wherever else it was before you sent off the build), and you can just keep on coding. There’s only a couple of small indicators that a build is running: For one, the jump bar at the top of the window turns blue as the build runs and cycles through the build tasks in the status area on the right. And if you’re in full screen “focus mode” with the code editor covering your entire screen, that’s all you see.

The application icon in the Dock or Task Bar also turns blue — which is handy if you actually are switching away from Fire or Water to some other app while you wait for a build. You can now see the build status and success/failure with one glance at the bottom of the screen (or even in the ⌘Tab app switcher, on Mac).

When the build finishes, jump bar and app icon either go back to normal (if all went well), or they turn red (if one or more projects failed to build). That, and an optional notification center message, is your only indication that the build is done — again, nothing happens that pulls you out of the flow, as chances are you just went right on coding while the build was happening.

Messages

Fire and Water have no dedicated “Error Messages” view that pops up when a build fails. Instead, build messages are integrated with the IDE’s regular navigation infrastructure: They fill into the jump bar at the top, for manual selection/browsing, and they also show inline in the text editor. Chances are, new build errors are happening right in the code you are currently working on, so having them show up where you are already looking at — the code window — is the best place for them, and in most cases, you need little else to find out what went wrong.

When you do, your favorite new keyboard shortcut will be ⌥⌘M / Alt+Ctrl+Shift+M (or the "<b<Messages|Show First Message" menu), which – as the name indicates – jumps right to the first message generated by the build. If there have been errors, it brings you to the first error that was encountered; if there were none, it brings you to the first warning or hint, if any.

Of course, you can also look at the jump bar, which shows you all build messages under the Build Log node, and select a message from there.

Once you navigated to a message, you can use the ^⌘Up and ^⌘Down (Fire) or Alt+Up and Alt+Down (Water) keyboard shortcuts (or "Project|Navigation|Up/Down" in the menu) to cycle between messages and jump from one to the other.

If you are the kind of person who does want to get distracted when building, Fire and Water do have a few options for you in the Preferences dialog, under Build & Debug: For one, you can choose to have the build log become visible either when a build starts, or only when it fails. This option can be helpful in certain situations (for example when you are “debugging the build”, i.e. when you’re in a development mode where you’re looking at build issues and expect to look at the build log a lot), but we really recommend not turning it on for day-to-day work. You can also optionally have Fire jump to the first error if a build fails (which is how many IDEs, such as Delphi and Visual Studio, behave – but again we recommend against it, for the reasons outlined above: it pulls out out of the flow when it happens).

Another cool thing you can do with build messages is copying code along with its messages to the clipboard. This is really helpful when you want to share a build problem with team-mates for help, or when you want to post questions about a build error somewhere. Simply select the range of code you’re interested in and press ⌘⌥C / Control+Alt+C (or "Edit|Copy w/ Build Messages" from the menu), and the IDE will copy the code as you expected — but it’ll add any error messages to the code as well (prefixed by a // comment delimiter, so that the copied code remains valid). Really handy.

Don’t Stop Me Now.

Sometimes you press ⌘B / Ctrl+C to start a build, and immediately regret it. You wrote some code, pressed “build” to see if it's any good, and the second you do, you spot that missing semicolon, that typo, or something else that’s just silly. In Visual Studio, you’d now sit there and wait for the build to finish, just to go again, and that always has been a huge frustration for us. Not so in Fire and Wateer.

There’s two things you can do when you started a build that you know will be no good. For one, you can press ⌘. / Ctrl+. (or "Project|Stop" in the menu) and cancel the build, immediately. Bam, it’s stopped. More interestingly, if you just fixed that silly typo and want to build again, you can just hit ⌘B / Ctrl+B again, and it will automatically cancel the current build and start fresh.

This might seem like a small thing, but you’ll find it a game changer in how you work – especially if you’re working on larger projects that take a few seconds to build. For example, a build of Fire itself takes between 30 seconds and two minutes, depending on how large a portion of the project rebuilds, and depending on what kind of Mac you're on (you really notice just how slow a 12" MacBook is, by comparison, when building large projects ;)). Not having to wait that out every time I make a mistake has been a huge productivity boost for me.

Incremental Build Messages

What makes this even more helpful is that error messages from the build will come in and show in the editor one by one, as the compiler encounters them. So even if your build takes, say, 10 seconds, chances are you see your current line of code turn red after just a second or two if you made a mistake. Just fix it, press build again, and off you go.

This is just a small overview of how Fire integrates the build cycle into the IDE, and many of its subtleties are hard to do justice by just describing them. Give Fire a spin for yourself to see how this all works out in action — and make sure to let us know what you think!

Fixed it for You!

Finally, there's a handful of common but trivial errors (such as case mismatch, or a missing ;, that the IDE can actually fix for you automatically. When the build finishes, you might see some of your errors turn from red to gray, with "FIXED" prefixed to the message.

Fire or Water just fixed the typo for you – no action needed!