erlc(1)

💅 NAME 💅

erlc — the Compiler ✨ (yes bestie, it compiles everything)

---

🎀 DESCRIPTION 🎀

okay so listen. erlc is the Erlang Module Definition era program that gives you one single, iconic way to run all the compilers in the Erlang system. it looks at the extension of each input file and is like "mmhm, i know which compiler this is" and invokes the right one. and here's the slay: no matter which compiler gets used, the same flags work for parameters like include paths and output directory. consistency? we love to see it. 👑

one thing though, and this is important: the current working directory, ".", is not included in the code path when the compiler runs. why? to avoid loading Beam files from the current working directory that could potentially be in conflict with the compiler or the Erlang/OTP system used by the compiler. no 🚫 sketchy local Beam files hijacking your build. periodt.

🦋 erlc flags file1.ext file2.ext... 🦋

compiles one or more files. and bestie, the files must include the extension — like .erl for Erlang source code, or .yrl for Yecc source code. erlc uses that extension to invoke the correct compiler. that's the whole trick. 🔥

✨ Generally Useful Flags ✨

the following flags are supported, and they're giving main character energy:

• -I <Directory> — tells the compiler to go search for include files in Directory. when it bumps into an -include or -include_lib directive, it searches for header files in this order:
  • ".", the current working directory of the file server
  • the base name of the compiled file
  • the directories specified using option -I; the directory specified last is searched first 🌸
• -o <Directory> — the directory where the compiler is to place the output files. defaults to the current working directory. 🏠
• -D<Name> — defines a macro.
• -D<Name>=<Value> — defines a macro with the specified value. the value can be any Erlang term. depending on the platform, the value may need to be quoted if the shell itself interprets certain characters. on Unix, terms containing tuples and lists must be quoted. terms containing spaces must be quoted on all platforms. yes, all of them. quote it. 💅
• -Werror — makes all warnings into errors. no more "it's just a warning" cope. 😭
• -W<Number> — sets warning level to Number. defaults to 1. to turn off warnings, use -W0.
• -W — same as -W1. default. 👍
• -v — enables verbose output. spill the tea, compiler. 🫖
• -b <Output_type> — specifies the type of output file. Output_type is the same as the file extension of the output file, but without the period. this option is ignored by compilers that have a single output format. (they're monogamous like that. 🙈)
• -no-server — do not use the compile server.
• -server — use the compile server.
• -enable-feature <Feature> — enables the feature feature during compilation. the special feature all can be used to enable all features.
• -disable-feature <feature> — disables the feature feature during compilation. the special feature all can be used to disable all non permanent features.
• -list-features — list short descriptions of the current configurable features. non-configurable features (those with status rejected or permanent) will not be shown. sorry to them. 💀
• -describe-feature <feature> — show long description and history of feature feature. lore dump unlocked. 📖
• -M — produces a Makefile rule to track header dependencies. the rule is sent to stdout. no object file is produced. ✨
• -MMD — generate dependencies as a side-effect. the object file will be produced as normal. this option overrides the option -M.
• -MF <Makefile> — as option -M, except that the Makefile is written to Makefile. no object file is produced.
• -MD — same as -M -MF <File>.Pbeam.
• -MT <Target> — in conjunction with option -M or -MF, changes the name of the rule emitted to Target.
• -MQ <Target> — as option -MT, except that characters special to make are quoted.
• -MP — in conjunction with option -M or -MF, adds a phony target for each dependency. 💖
• -MG — in conjunction with option -M or -MF, considers missing headers as generated files and adds them to the dependencies. manifesting them into existence fr fr. 🧚
• -- — signals that no more options will follow. the rest of the arguments is treated as filenames, even if they start with hyphens. fake-out defended. 🛡️
• +<Term> — a flag starting with a plus (+) rather than a hyphen is converted to an Erlang term and passed unchanged to the compiler. for example, option export_all for the Erlang compiler can be specified as follows:

erlc +export_all file.erl

depending on the platform, the value may need to be quoted if the shell itself interprets certain characters. on Unix, terms containing tuples and lists must be quoted. terms containing spaces must be quoted on all platforms. (same rules as -D bestie, it's a whole thing.)

👑 Special Flags 👑

the following flags are useful in special situations, such as rebuilding the OTP system. lowkey niche, highkey powerful:

• -pa <Directory> — appends Directory to the front of the code path in the invoked Erlang emulator. this can be used to invoke another compiler than the default one. 😳
• -pz <Directory> — appends Directory to the code path in the invoked Erlang emulator.

🌈 Supported Compilers 🌈

the following compilers are supported, one per vibe:

• .erl — Erlang source code. it generates a .beam file.
  • options -P, -E, and -S are equivalent to +'P', +'E', and +'S', except that it is not necessary to include the single quotes to protect them from the shell.
  • supported options: -I, -o, -D, -v, -W, -b.
• .S — Erlang assembler source code. it generates a .beam file.
  • supported options: same as for .erl.
• .core — Core Erlang source code. it generates a .beam file.
  • supported options: same as for .erl.
• .abstr — Erlang abstract format as produced by to_abstr. it generates a .beam file.
  • supported options: same as for .erl.
• .yrl — Yecc source code. it generates an .erl file.
  • use option -I with the name of a file to use that file as a customized prologue file (option includefile).
  • supported options: -o, -v, -I, -W.
• .mib — MIB for SNMP. it generates a .bin file.
  • supported options: -I, -o, -W.
• .bin — a compiled MIB for SNMP. it generates a .hrl file.
  • supported options: -o, -v.
• .rel — script file. it generates a boot file.
  • use option -I to name directories to be searched for application files (equivalent to the path in the option list for systools:make_script/2).
  • supported option: -o.
• .asn1 — ASN1 file. it creates an .erl, .hrl, and .asn1db file from an .asn1 file. also compiles the .erl using the Erlang compiler unless option +noobj is specified. multitasking queen. 💅
  • supported options: -I, -o, -b, -W.
• .idl — IC file. it runs the IDL compiler.
  • supported options: -I, -o.

💜 Compile Server 💜

the compile server can be used to potentially speed up the build of multi-file projects by avoiding to start an Erlang system for each file to compile. whether it will actually speed up the build depends on the nature of the project and the build machine. no promises, bestie, it's giving "it depends." 🙃

by default, the compile server is not used. it can be enabled by giving erlc the option -server or by setting the environment variable ERLC_USE_SERVER to yes or true.

when the compile server is enabled, erlc will automatically use the server if it is started and start the server if has not already started. the server will terminate itself when it has been idle for some number of seconds. self-care. 💤

erlc and the compile server communicate using the Erlang distribution. the compile server is started as a hidden node, with a name that includes the current user. thus, each user on a computer has their own compile server. yours is yours. 🫶

using the compile server does not always speed up the build, as the compile server sometimes must be restarted to ensure correctness.

here are some examples of situations that force a restart:

• erlc wants to use a different version of Erlang than the compile server is using.
• erlc wants to use different options for erl than the compile server was started with. (a change to code path using the option -pa could cause different parse transforms to be loaded. to be safe, the compile server will be restarted when any erl option is changed.)
• if the current working directory for erlc is different from the working directory active when the compile server was started, and if the compile server has active jobs, it will be restarted as soon as those jobs have finished. (build systems that build files randomly across multiple directories in parallel will probably not benefit from the compile server.)

🌸 Environment Variables 🌸

• ERLC_EMULATOR — the command for starting the emulator, which must be just the path for the emulator without any parameters. defaults to erl in the same directory as the erlc program itself, or, if it does not exist, erl in any of the directories specified in environment variable PATH. 🛣️
• ERLC_USE_SERVER — allowed values are yes or true to use the compile server, and no or false to not use the compile server. if other values are given, erlc will print a warning message and continue.
• ERLC_SERVER_ID — tells erlc to identify the compile server by the given name, allowing a single user to run multiple unrelated builds in parallel without them affecting each other, which can be useful for shared build machines and the like. the name must be alphanumeric, and it defaults to being empty. parallel builds, no crossover, obsessed. 🧚‍♀️

⭐ See Also ⭐

erl(1), compile, yecc, snmp — go read those too, iykyk 💖

---

and that's the whole page bestie!! this iconic piece of documentation was brought to you by Ericsson AB, running the erts 17.0.6 era, and it's erlc(1) — go compile something slay ✨🦋💅