Search code examples
csublimetext3

How to always link math in sublime text?


Whenever I want to build a C program with math functions, it complains about undefined references because sublime text 3 does not link math by default.

What I tried:

  • Find the default build system so I could add -lm, but I could not find it.
  • add #pragma comments:
#include <math.h>
#pragma comment(lib, "math")
#pragma comment(lib, "m")
#pragma comment(l, "math")
#pragma comment(l, "m")
#pragma comment(math, "math")
#pragma comment(m, "m")

None of which worked


Solution

  • The build systems for compiling C/C++ programs are C Single File.sublime-build and C++ Single File.sublime-build respectively. Both are contained in the C++ package (as are their syntaxes).

    As you've noted, the command lines provided in these build systems are very simplistic and meant for simple, single file programs. Anything outside of that is really the purview of a more dedicated build environment, such as make and the like (Sublime supports Makefile builds out of the box).

    The build systems themselves are inside of sublime-package files, which is why you won't find them by searching your file system. There are two ways to go about making an adjustment like this; you can create a new build based on the built in ones, or you can override the internal ones.

    Creating a new build

    1. Use View Package File from the command palette, and then enter C single file to filter the list of package resources down, and select C++/C Single File.sublime Build (or the C++ one, as appropriate) to open the resource.

    2. The file will open read-only because it's stored inside of a package; use Tools > Build System > New Build System... from the menu to create a stub build system template

    3. Copy the text from the opened file and use it to replace the text in the stub file.

    4. Adjust the build/command line as appropriate, then save the file as a sublime-build file in the location that the save dialog defaults to (which is your User package)

    The build will now be available under the name that you saved it as; you can select it directly or set the build system to Automatic and use Tools > Build With... for your first build so that Sublime prompts you for the build system to use (it will remember your decision after you pick it).

    Override the internal build system (manually)

    1. As Step #1 above, open the build system you want to override; hover your mouse over the tab and note the filename, which will appear to be in your normal Packages directory even though the file doesn't exist there.

    2. Use Preferences > Browse Packages to open the Packages folder in a file browser. If there's not already a folder for the package that the build is contained in (here C or C++), create one

    3. Save the opened build system, which will drop it into the folder you just created.

    4. The file buffer won't let you type in it because it was originally opened in from a sublime-package file; close the file and re-open it with File > Open Recent > Reopen closed file and make edits as needed.

    Since you're overriding the internal build system, you can continue building as you did previously.

    Override the internal build system (via OverrideAudit)

    1. Install the OverrideAudit package (disclaimer: I am the author)

    2. Open the resource as in step #1 in the other methods

    3. Right click in the file and choose OverrideAudit: Override this resource or choose OverrideAudit: Override Current Resource from the command palette

    4. The buffer is now editable; make changes as desired and then save the file as normal to create the override (if you close the file without making changes, nothing happens)

    As above, building as you do currently will continue to work since you've overridden the internal file.


    If you use either of the override methods, you end up with a file in your Packages folder whose name and location exactly mimics the name of the file from the source sublime-package file.

    Sublime will use that resource in place of the original file in perpetuity, even if the source file changes (new features, bug fixes, is removed, etc). That can potentially cause issues (though for build systems the risk is pretty minimal).

    The OverrideAudit package above performs checks on Sublime and package upgrades to warn you if this might be a problem and contains other features that let you see exactly what you're overriding and how. For that reason I'd recommend it if you want to go the override route.

    All of these methods are also demonstrated in my video on safely modifying package files as well,if you'd like to see it in action.