Allows customizing the arguments handed over to the Erlang VM, e.g. to
set a name or a cookie, e.g. by setting escript_emu_args to:
%%! -name rebar -setcookie rebar
Calling erlang:system_info(wordsize) yields the internal word size of
the Erlang emulator. But due to the halfword emulator, need to pass
{wordsize, external} instead to get the word size, or pointer size, as
seen by external code such as NIFs. The halfword emulator has 4 byte
internal words but 8 byte external words due to 64-bit compilation,
which means NIFs for the halfword emulator also have to be compiled
64-bit. But just passing wordsize is equivalent to passing {wordsize,
internal}, which does not indicate the pointer size for the halfword
emulator.
Older versions of Erlang do not support {wordsize, external}, though,
so continue to pass just wordsize for those versions.
Change the second parameter of a regex tagged port_source from being a
filename or wildcard to being a list of filenames or wildcards.
Previously: {"R14", "c_src/*.c"}
Now: {"R14", ["c_src/*.c"]}
Motivation for change is to avoid repeating regexes.
get_apps/3 now returns which apps have been added, removed and ugpgraded
in a reasonable way. It should prove more usable should we want to
access any of those lists in future appup related changes.
This patch makes a small change in rebar_core that checks the list
of valid plugins to see if any of them export a pre/post processing
function for the current command. This logic is applied only to the
plugins and allows plugin authors to hook into rebar's execution by
using a naming convention that matches the one used for scripting hooks.
Example:
```erlang
-module(my_rebar_plugin).
-export([pre_compile/2]).
pre_compile(Config, AppFile) ->
rebar_log:log(debug, "PRECOMPILE: ~p:~p~n",
[AppFile, Config]),
ok.
```
The logic changes from strict overrides to a hybrid for merging os_env
and defaults, whereby defaults are chosen if they are not set in the
os_env or if the defaults contains substitutions (at which point os
environment is substituted).
This still means that rebar.config works as it did before, where it
overrides or substitutes based on the use of $VAR, but that default
and os environment merging works such that the common cases of
providing CC or LDFLAGS in the users environment or command line work
as you might expect. In that CC is overriden by the os environment
unless rebar.config overrides it, and LDFLAGS from the user environment
is appended or prepended based on defaults and rebar.config.
Addresses problems with https://github.com/basho/rebar/pull/71
Also keeps the fix for bug 255.
This patch allows the 'suite' argument to eunit to be a comma separated
list of modules to test instead of being a single module. This allows
fine-grained testing when one test suite interferes with another and its
not clear which suite is causing the problem. It also lets you run the
test suite in a different order for a similar reason.
The other enhancement is to add a new eunit parameter; 'skip_app' which
like 'app' is a comma separated list of modules to skip testing on. This
parameter is only applied if the app parameter is not passed. Its
purpose is to avoid forcing you to specify all the apps to test if you
only want to skip a handful and there are many apps to test.
This change makes it possible to assign pre/post scripts to all
rebar commands. This allows users fine grained control over
when scripts and/or shell commands should be executed, where such
extensions are absolutely needed.
Several examples have been added to the rebar.config.sample file.
This commit changes how rebar determines which apps have been
updated, added and removed from a release during appup generation.
Rather than use app files it now determines this from the rel file
in each version of the release. In addition it fixes a bug reported
on the mailing list when generating appups when an application has
been added or removed from either release.
Rebar will exit with {error,bad_directory} when trying to restore the code
path after it has finished working on a subdirectory if there are invalid
relative paths in it. The problem was seen when executing the last line of
rebar_erlc_compiler:doterl_compile/3 (true = code:set_path(CurrPath)).
This change adds support for executing ct test runs based on test
specificiations, which was missing previously. The rebar_ct module
now looks for any number of files with a name ending in `test.spec`
and if it finds one or more, passes these after the `-spec` argument
to ct_run instead of explicitly configuring the config, user config
and coverage config variables.
When no specifications are found, then the module behaves as it did
before this change, and both the ct1 and (new) ct2 integration tests
appear to show this is a backwards compatible patch.
To further support OTP releases I have added support for generating
application appup files. These include instructions that systools uses
to generate a relup file which contains the low level instructions
needed to perform a hot code upgrade. My goal with this module is to
produce "good enough" appup files or at least a skeleton to help one get
started with something more complex. If an appup file already exists for
an application this command will not attempt to create a new one.
Usage:
$ rebar generate-appups previous_release=/path/to/old/version
Generally this command will be run just before 'generate-upgrade'.
If an app uses -include_lib for its own included files, compilation
fails if the app directory isn't in $ERL_LIBS because code:lib_dir/1
will return an error. An absolute path needs to be added to code path
instead of just "ebin".
In git origin/HEAD is a pointer to the default branch. This patch
allows two alternatives to explicitly specifying "HEAD" in git VC specs.
The first is a 2 arity form {git, Url} and the second is {git, Url, ""}
which worked in pre-update-deps rebars.
To support OTP release upgrades I have added support for building
upgrade packages. Support for this is included in the
rebar_upgrade module, specifically generate_upgrade/2. It requires
one variable to be set on the command line 'previous_release' which
is the absolute path or relative path from 'rel/' to the previous
release one is upgrading from. Running an upgrade will create the
needed files, including a relup and result in a tarball containing
the upgrade being written to 'rel/'. When done it cleans up the
temporary files systools created.
Usage:
$ rebar generate-upgrade previous_release=/path/to/old/version
This also includes a dummy application that can be used to test
upgrades as well as an example.
Special thanks to Daniel Reverri, Jesper Louis Andersen and
Richard Jones for comments and patches.
This change makes it possible to type the beginning (the prefix) of a
command name and rebar will guess the full name of the command,
thereby saving the user precious keystrokes. As long as the prefix
matches only one command, rebar runs that command, otherwise rebar
prints a list of candidate command names. The "-" character is
considered to be a word separator and the prefix matching is done per
word.
Example prefix matches:
co ==> compile
cl ==> clean
create ==> create
create-a ==> create-app
c-a ==> create-app
c-app ==> create-app
On one project I have a need to specify port_sources on R14 only
and on another different project port_sources for Darwin and Linux.
To this end add support to handle tuples of the form
{ArchRegex, PortSource} in the port_sources list, eg:
{port_sources, [{"R14", ["c_src/*.c"]}]}.
This patch remedies an issue where the ebin directory would be
erroneously created as a file by the first "mv" command in
rebar_protobuffs_compile.erl [line 106] if the ebin file did not
exist at the root application level.
In essence, the patch ensures that the ebin directory exists at
the application directory level before any "mv" commands are
executed. The following code was inserted at line 106:
ok = filelib:ensure_dir(filename:join("ebin","dummy")),
abnfc is an ABNF parser generator.
Options are:
- doc_root (defaults to "src")
- out_dir (defaults to "src")
- source_ext (defaults to ".abnf")
- module_ext (defaults to "")
Add support for defining template variables of the following form:
{variables, [{appid, "mochiwebapp"},
{author, "Mochi Media <dev@mochimedia.com>"},
{year, "2010"},
{version, "0.1"},
{port, 8080},
{dest, "{{appid}}"}]}.
Where dest may be overridden on the commandline but will default to
being the appid. Mochiweb uses this so that we can create new
projects from the template in a configurable directory.
So
$ rebar create template=mochiwebapp dest=foo appid=bar
I thought about special casing dest but figured it might be generally
useful to be able to nest template vars.
However this patch only does one level of resolution. So if
{variables, [{foo, "{{bar}}"},
{bar, "{{foo}}"}]}.
then bar will end up being the literal string {{bar}} and foo the
literal string {{foo}}.
mustache:render("{{banan}}", dict:from_list([{banan, true}])).
** exception error: no function clause matching mustache:escape(true,[])
in function erl_eval:do_apply/5
in call from erl_eval:expr/5
in call from erl_eval:expr/5
in call from mustache:render/3
- Check the existence of first_files and fail if they are not present
- Get first_files lists from local instead of inherited config
definitions, since they only make sense in the local context
Using rebar's commandline, enable/disable 'debug_info' for
compilation. This feature if added to all rebar compilers could help
simplify and standardize this common use case for all rebar build
targets.
Modify rm_rf and cp_r to work when {win32,_} = os:type().
Simplify rm_rf to only accept one filename, directoryname or wildcard.
Add unit tests to ensure a similar behaviour on windows and unix.
Thanks to tuncer for guidance and feedback.
The eunit_dir() does use the ?EUNIT_DIR macro internally, but it also builds, what I guess is, an absolute path, which might be better :) At least it's more consistent.
Normally the ebin directory doesn't contain any source files. Therefore it won't be kept in the repository by, at least, mercurial and also maybe git unless you put some .keep file in it or do some other hack. The ebin directory is created by rebar compile, but if rebar eunit is called before rebar compile, you end up with a {'EXIT', {{badmatch,{error,bad_directory}},...}. Another approach would be not to match cod:add_pathz(ebin_dir()) with ok, but I think this is an ok solution as well.
The previous code in rebar that was trying to ensure that parse
transforms and behaviours were compiled first doesn't work with multiple
compiler workers because of the possiblity of one of the workers
compiling a file that needs a parse transform or a behaviour at the same
time another worker is compiling that same parse transform or behaviour.
The solution this patch implements is to append any parse transforms and
any behaviours (in that order) to erl_first_files to ensure that they
are compiled before any regular files. This patch won't break any
currently working uses of erl_first files because we only append to the
list, so anything in erl_first_files is still compiled before anything
else.
Add a coverage report similar to the one output to index.html except
that it is output to the terminal if the new rebar.conf option
'cover_print_enabled' is set to true.
The previous fix to relax the regex was insufficient.
This is basically the diff proposed by Bryan Fink with
the difference of using 'C' instead of 'en_US'.
Rebar currently doesn't give any feedback on an invalid command. This change
makes rebar keep track of how many operations each command triggers, if a
particular command doesn't change the count, there were no modules implementing
it. If at the end of handling all commands, tje count is 0, none of the supplied
commands were valid and ?FAIL is called to trigger a non zero exit status.
Replace rebar_util:get_cwd/0 by rebar_utils:get_cwd/0. Luckily the
misspelt module name doesn't seem to have caused any harm, since
rebar_app_utils:is_app_dir/0 and rebar_rel_utils:is_rel_dir/0 aren't
called (only their /1 counterparts).
*If* there is a deps_dir tuple in the root rebar.config then
that is used globally as the deps dir. This is to stop dependencies for dependencies being
created in a different deps_dir even if the sub dependency so specifies.
Modules that include the EUnit header get an implicit test/0 fun,
which cover considers a runnable line, but eunit:(TestRepresentation)
never calls. Result: prod modules with tests can never reach 100%
coverage. Ironic. In this case, fix it by decrementing the NotCovered
counter returned by cover:analyze/3.
1. When running the eunit command with the convention of putting
tests in "*_tests" modules, eunit would run those tests twice. This
is because: 1) eunit:test/1 will naturally look for foo's tests both
in foo, and in foo_tests, and 2) eunit:test/1 was being folded over
all project modules. The fix is to filter "*_tests" modules from the
list passed to eunit:test/1.
2. When running the eunit command with cover enabled and tests in a
'test' directory, cover would error because it couldn't find the
source code for those tests. This is because cover:analyze/3 will
only find module source in "." and "../src". This is hard-coded in
cover :-(. Since cover shouldn't be calculating code coverage on test
code anyway, the fix is to not fold cover:analyze/3 over
non-production code.
3. When running the eunit command with cover enabled and a test suite
defined, cover would only attempt to calculate coverage on the the
test suite itself. This was because only the suite was passed to
cover:analyze/3. The fix is to fold cover:analyze/3 over all the
production code, filtering out the suite module if it is defined.
{file,In,Out,true} = render with mustache
{file,In,Out,false} = do not render with mustache (leave as-is)
old-form {file,In,Out} is equivalent to {file,In,Out,true}
eg. rebar eunit -- runs all tests in all modules
rebar eunit suite=foo -- only runs tests in foo.erl/foo_tests.erl
Added an entry to .hgignore to avoid .swp files (created by VIM).
