Integrating Your Development Workflow Into Sublime With Build Systems, Part 2: Options and Variables
Join the DZone community and get the full member experience.Join For Free
If you watched part 1, you’ll know we finished off after running our first build system, and we saw that it listed the contents of the User Packages directory. This was because, by default, the build command’s working directory is the directory that the build file is saved in. In this episode, we’re going to see how we can change this from the default as well as take a look at some of the other features that build systems give us.
So we’ll go back to our little build system file and make one quick edit.
All we’re going to do right now is add a working directory option in here, which, for right now we’ll simply set it to the root of my C drive for simplicity’s sake and save the file.
If we run it again, we can see that the results show the contents of my
C drive instead of my User Packages directory. As you can see, by adding options to our build, we can gain greater control over how our commands run, and I highly recommend you check out the documentation to see what all the possible options are. But we can do more than just set some options. What if we don’t want the working directory to be hard-coded, but instead be based off of what I’m working on? Well, for that sort of thing, we need variables.
For this build system, we’ll set the command as
"node", but that will just run the Node REPL since we haven’t given Node a script to run. Actually, let’s see what that looks like since we’re talking about it. We’ll save this as
Then we’ll select Node as our active build system, and run it.
You’ll notice the results panel shows up, but we’re not seeing any output. That’s because we’re in the REPL, and it’s waiting for our input. Sadly, we can’t give it any input from here, nor can we hit
ctrl+c to kill the process, so how are we going to stop it?
We do that with
Tools > Cancel Build. There, now it says it was canceled which means the process is no longer running.
Now we’ll give Node a file to run, which we’ll do by using the
$file variable would be empty.
Now let’s run the build (we don’t need to select the build system to run since it should still be selected) and we get an error. What happened? Well, if you look up here, it’s saying that a module is missing, that usually means that Node is trying to load a file and can’t find it. In this case, we’re only trying to load the one file that we specified, so we’re not missing any dependencies. Now look at the path it’s looking for. That’s odd. That’s the correct start to our path, but it’s cut off. Turns out, the path we’re using has a space in it!
We’ll need to make sure that the file’s path is wrapped in quotes in order to avoid this problem.
Now let’s save it, run it, and we can see that the script we had open was run and the expected output can be seen.
If you want to see more of the variables that you can use in your build systems, you can read the documentation, which I’ve linked to in the description below the video. In the next video, we’ll combine multiple build systems into one file to organize related builds, simplify how we switch build systems (since there is no simple keyboard shortcut to choose a different build system), and keep the list of build systems from getting absurdly long.
It was great seeing you all again for this tutorial. Keep watching to get through the rest of the series in order to get to Build System paradise…ish. God Bless and happy coding!
Published at DZone with permission of Joseph Zimmerman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.