You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gazelle language extension for erlang. Should be considered
experimental. Breaking changes may still be made in the extension
without a major version bump to rules_erlang.
Supports BUILD file generation for hex, rebar & "bare" erlang
apps (erlang sources in the typical layout). Not all hex and rebar
information is imported - notably rebar "profiles" are not yet handled.
The extension generates a "fine-grained" build. In "classic"
rules_erlang, the erlang_app/test_erlang_app macros compile all beam
files for a given application in one or two invocations of `erlc`. The
gazelle extension instead generates a rule per beam file, resulting in
an invocation of `erlc` for each. This improves caching, though is
probably somewhat slower on the first compilation of an app. It also
allows apps that require more than 2 compilation "phases" to work
directly. As this results in many more rules in the BUILD file, the
`erlang_generate_beam_files_macro` directive can be used to instead
declare most of rules in an `app.bzl` file imported by the BUILD file.
The extension also provides some support for the gazelle
"update-repos" command. The -from_file option can be used with
rebar.lock files. Can also be run with references to hex.pm or
github.com to import dependencies directly. This is non-recursive,
though transitive deps are printed for convenience. This is deliberate
design decision, as bazel prior to version 6 with bzlmod does not have
a built-in mechanism for handling of transitive deps.
The extension generates a `moduleindex.yaml` file in the repo root,
which is used as an index of which modules are contained in a given
erlang application. This allows calls at runtime of a given module to
be mapped to the appropriate dependency. It's updated by both the
default fix/update commands, as well as update-repos, so it's
recommended to check it into VCS.
A number of gazelle directives are supported to help customize BUILD
file generation:
- erlang_behaviour_source_lib
- erlang_exclude_when_rule_of_kind_exists
- erlang_generate_beam_files_macro
- erlang_always_generate_test_beam_files
- erlang_skip_rules
- erlang_apps_dirs
- erlang_app_dep
- erlang_app_dep_ignore
- erlang_app_extra_app
- erlang_no_tests
Other changes:
Some new versions of existing rules are added, such as
`erlang_bytecode2` and `assert_suites2`.
erlang_bytecode2 compiles with transitive deps
since gazelle generates minimal deps, we need to include the
transitive deps so that, for instance, headers include headers of deps
are present.
For compilation, we actually don't need all the files from a dep, just
public headers and compiled behaviours. In fact, only the transient
headers are needed, not the transient behaviours. So this could be
optimized.
erlang_build rule produces tars, not directories - this simpilies the
"installation" of internal erlang builds in other rules
assert_suites2 macro does not require passing the list of existing
rules explicitly
self referencing include_lib directives are supported
The -hidden flag is used for ct_run
0 commit comments