To avoid treating plugins' info/2 functions as commands, we catch calls
to 'rebar info'. Previously (4b8c81fb) we simply printed the help
string, but it's much more informative to print the following:
Command 'info' not understood or not applicable
Previous generate-upgrade required renames in rel/ directory:
rebar generate
...changing code...
mv rel/<release> rel/<release_prev>
rebar generate
rebar generate-upgrade previous_release=<release_prev>
With the proposed changes you can now do the same without moving things:
rebar generate # default target dir: rel/<release>
...changing code...
rebar generate target_dir=<release_new>
rebar generate-upgrade target_dir=<release_new> previous_release=<release>
rebar used to mistakenly report plain version strings like
{vsn, "1.0.0"} as follows:
DEBUG: vcs_vsn: Unknown VCS atom in vsn field: "1.0.0"
Properly detect unknown/unsupported version terms and abort
if we encounter one.
While at it, rename a variable in vcs_vsn/3 to be non-misleading.
Rebar, when it encounters a lib_dir directive, caches the current code
path, adds the libdir(s) and returns the cached copy of the path. When
rebar has finished processing that directory, it restores the cached
path. This is problematic in the below scenario:
/(lib_dir)->G
A -> B -> C -> D -> E
\-> F -> D -> E
When rebar is finished processing B, it restores the code path to what
it was before it processed B, removing C, D, E and G from the code path.
This means when it comes to process F, neither D or E are in the code
path, so any header includes, rebar plugins or parse transforms will not
be in the code path. Without the lib_dir directive, rebar does no code
path cleanups, so everything works fine.
This change makes rebar only remove the explicit lib_dir code paths it
added and adds an inttest that replicates the above scenario.
Sometimes tags like 1.1-3-g3af5478 or d20b53f0 are encountered. The
first is the output of 'git describe', and the second is just a regular
git SHA. git fetch --tags will not pull these down, so do a full git
fetch instead.
Because rebar_core handles skipping apps, we had to specialcase the
handling in the case of update-deps because it has to do its own dep
handling. The way this was done is not particularly clean, but there
currently does not exist another way for a command to signal rebar_core
that it doesn't want rebar_core to pay attention to skip_apps.
With this change, however, you can update-deps even with local
conflicting changes/commits by simply skipping the deps you don't wish
to update, or whitelisting he ones you do wish to update.
Previously, update-deps on a dep tagged as {branch, ...} would do the
following:
git fetch
git checkout -q origin/<branch>
If you were already on that branch, the repo would end up in detached
head state. This is kind of annoying if you're doing local development.
This patch changes the behaviour to be
git fetch
git checkout -q <branch>
git pull --ff-only --no-rebase -q <branch>
The intent of this is to move the branch's HEAD forward to match
upstream without destroying any local commits or changes, and without
accidentally causing merges or rebases. It will fail if the operation
can not be performed without losing history, merging or rebasing.
The previous behaviour has been around a very long time:
064195dc5a (L0R308)
It also exactly mirrors the download_source case, which is not really
true. With git tags and SHAs, one can assume that they don't change, but
branches move all the time.
The order in which modules, within an application, are loaded can be
important. This patch adds allows the specification of module
dependencies such that generate .appup/.relup scripts will load a
module's dependent modules before itself.
To use:
in rebar.config, add a module_deps
{module_deps, [{ModuleName, [DependentModuleName, ...]}]}.
ModuleName is the name of any module, followed by a list of module
names that it depends on.
The call to the grep program in rebar_ct:check_log/3 used single
quotation marks around the strings grep should search for. This works
well in most cases but fails on Windows 7 using GNU grep 2.5.4 as
installed by the Chocolatey package GnuWin 0.6.3.1 with the follow
message:
ERROR: cmd /q /c grep -e 'TEST COMPLETE' -e '{error,make_failed}'
ct/raw.log
failed with error: 2 and output:
grep: COMPLETE': No such file or directory
This commit changes the single quotation marks to double quotation
marks. I've tested this using GNU grep 2.5.3 on a Debian Linux machine
and it works well.
This ensures that deps of deps are updated AFTER the dep listing them
is, so that a complicated project with many layers of deps will be
updated correctly. Any new deps encountered along the way are also
cloned, and THEIR deps are also evaluated.
Also added was conflict detection, if a dep has differing versions or
source information, inherited from different places, that will be logged
at the end of update-deps, along with the origin of each conflicting
dep.
Previously, the configuration setting 'mib_opts' in rebar.config
would affect the call to snmpc:compile/2, so that (for example)
verbosity could be controlled. However, the subsequent call to
snmpc:mib_to_hrl/1 did not include any of these options, so it
did not appear to be possible to control the verbosity of the
process of converting a MIB to a .hrl file. To make matters
worse, the default was to dump a full trace -- including debug
output and various logging -- so the act of compiling a large
number of MIBs could result in a huge amount of "noisy" output
that hid any signal (meaningful warnings, errors, etc.).
This commit addresses that issue by replacing the call to
snmpc:mib_to_hrl/1 with a call to snmpc:mib_to_hrl/3 instead,
which includes an "options" argument that, at present, is only
capable of setting verbosity. The verbosity setting is taken
from the 'mib_opts' setting in rebar_config, if present, and
the approriate kind of argument is passed to snmpc:mib_to_hrl/3.
It should be noted that snmpc:mib_to_hrl/3 is not listed in
Erlang's documentation, but does appear in the list of "API"
exports at the top of snmpc.erl in R15B01 (and remains that way
in R16B01), so this appears to be more of a documentation oversight
than the use of a deep, dark function call that was not intended
to be public. snmpc:mib_to_hrl/3 accepts an #options{} record
(defined in lib/srdlib/include/erl_compile.hrl within Erlang's
source distribution), though most of the fields in that record
are ignored by snmpc:mib_to_hrl/3; only verbosity can be controlled
this way.
- restore support for "rebar help xref"
- update rebar.config.sample
- update 'help xref' string
- simplify new/changed functions by breaking out code or
using simpler syntax where applicable
- refactor plugin dirs code to be simpler and easier to read
- use erlang-mode's default (%%) comments for portability/consistency
- make sure erlang-mode's indenter is used so that a future whole
buffer indent doesn't get messed up
The external deps_dir should have higher priority because
it is used by scripts and other build tools to set up the
location of the dependencies. This commit ensures that,
even if a project has set deps_dir in its config file has
lower preference than the command line one.
This commit fixes issue #98 by removing the ERL_LIBS and REBAR_DEPS_DIR
from the list of environment variables exported by the rebar_port_compiler
plugin.
Since R15B02, ct_run returns a non-zero exit code when some tests
failed or were auto-skipped. (See ticket OTP-9865.)
This fix makes it so a non-0 code doesn't cause an instant failure, but
still prompts for log verification before doing so. Given the behaviour
was acceptable for pre-R15B02, it should be valid with it with
post-R15B02.
The fix should also be backwards compatible.
This commit add support for reading mustache 'lists' from files, so you
can use the list section functionality when templating things.
An example of the list syntax is as follows:
{package_commands, {list, [[{name, "riak"}], [{name, "riak-admin"}], [{name, "search-cmd"}]]}}.
Then you can, for each of the list elements, render some text:
{{#package_commands}}
chmod +x bin/{{name}}
{{/package_commands}}
* Allow the following predefined analyses :
undefined_function_calls, undefined_functions, locals_not_used,
exports_not_used, deprecated_function_calls, deprecated_functions
* Trap some possible errors in case module information is not
available
* ignore_xref works on all checks and can take {M,F,A} tuples.
(Automatic behaviour export suppression still only works on
exports_not_used)
One could argue that rebar_eunit does some pretty dangerous stuff when
trying to clean up after a test run, but specifically, it tells the
Application Controller to delete everything returned by
application:get_all_env(App). Unfortunately, included_applications
also goes, which can lead to a crash in application_controller, if
the application is subsequently unloaded.
This patch attempts the smallest possible fix: remove all env
variables except included_applications.
The results returned by os:getenv() may contain unicode characters.
That said, we need to explicitly allow unicode when splitting the
environment information, otherwise badarg will be raised causing all
rebar commands to fail until the environment variable is removed.
Normally, Rebar runs eunit tests in the order the beam files are
stored in the file system (see rebar_utils:beams). However, sometimes
it is desirable to run the tests in a different order (e.g. to
reproduce an error found on a build server). For that case, it would
make sense to use the 'suites' parameter not just for selecting which
modules to consider, but also for choosing the order.
Add skip_deps=AppListSeparatedByCommas feature.
I agree it's a bit of a weird thing, but it's a reasonable and safe extension. When time comes to properly overhaul stuff, skip_deps should disappear entirely.
This allows `rebar ct suites=abc` to consider all suites when
you have a rebar setup with multiple sub_dirs.
Previously, rebar halted after it could not find the suite in the
first dir. But the suite might be present in another dir (when
sub_dirs contains multiple dirs).
This commit makes it so instead of halting, it prints a warning and
continues with looking for the suite in the other `sub_dir`s.
Note -- This uses try/catch to cause the test to be skipped because
otherwise I needed to adjust the return values of 4 functions, the
code path is pretty deeply nested here. Otherwise the whole call chain
needed to be adjusted for this return value:
`run_test -> make_cmd -> get_suites -> find_suite_path`
IMHO, I think for exceptional cases like this it is fine to use throw;
specially since only the {skip} is catched and nothing else.
When a DTL template includes other template files, those files don't need
to be compiled separately, and therefore can be given an extension different
from `source_ext` (such as `.dtli`) to avoid being compiled. This fix
allows rebar to find included dependencies with names `*.dtl*` rather
than `*.dtl` and properly determine if a template file needs to be recompiled.
Handle the case where the error didn't occur in the file being
compiled. That is, if there is an error on line 9 of bar.hrl,
instead of:
/path/to/foo.erl:9: type foo() already defined
print:
/path/to/bar.hrl:9: type foo() already defined
The printed message is made more terse.
Example before applying patch:
ERROR: Compiling template src/view/test.dtl failed:
{error,{"src/view/test.dtl",
[{{4,7},
erlydtl_parser,
["syntax error before: ",["\"\\\"HELLO_WORLD\\\"\""]]}]}}
Example after applying patch:
ERROR: Compiling template "src/cmp_html_error_template.dtl" failed:
(line:3, col:12): ["syntax error before: ",["trans"]]
Added a backward compartible feature to specify `erlydtl_opts' options
for the DTL template compiler to allow inclusion of templates in different
directories with different compilation settings for each. E.g.:
{erlydtl_opts, [
[{doc_root, "src/view"}, {module_ext, "_dtl_vw"}]
, [{doc_root, "src"}, {module_ext, ""}, {recursive, false}]
, {out_dir, "ebin"}
, {compiler_options, [verbose, debug_info]}
]}.
The definition above is identical to this (the last two options
are duplicated in each list):
{erlydtl_opts, [
[{doc_root, "src/view"}
,{module_ext, "_dtl_vw"}
,{out_dir, "ebin"}
,{compiler_options, [verbose, debug_info]}]
, [{doc_root, "src"}
,{module_ext, ""}
,{out_dir, "ebin"}
,{compiler_options, [verbose, debug_info]}
,{recursive, false}]
]}.
In this case "src/view" and "src" directories containing template files
will be compiled. A new `recursive' option tells rebar_erlydtl_compiler
to search files recursively from a given doc_root. In the example above
the "src" directory won't be scanned recursively, and the target template
name for target beam modules won't have "_dtl_vw" suffix.
