If I pass an expression like: "$PWD/deps/local/lib" in the port env
string, it expands to "/deps/local/lib", (variable is expanded to the
empty string) but if I pass "${PWD}/deps/local/lib" it expands
properly. I found that confusing.
This was because we require environment vars to end with whitespace,
while I think requiring a non-word character would be sufficient, since
the variables can only contain word characters.
This changes the expansion system to recognize variables that are
terminated by non word characters.
This includes some fixes as per some comments by tuncer.
Fixesrebar/rebar#457
Similar to how .app.src are being handled, all files in directory
.src ending with .appup.src are processed, checked for
correctness and copied to ebin without the .src extension.
By way of using rebar_config:consult_file/1, .appup.src.script
files are automatically supported in exactly the same manner
as in .app.src.script.
Remove possible last dot from deps dir path by calling
dirname on base_dir, deps_dir and dummy path part.
With this fix delete-deps command deletes dependencies
properly in case of deps dir path ended with dot.
Examples of deps_dir config value that triggers error:
".", "some/path/.".
Code that triggers error: rebar_deps:'delete-deps'/2,
code line lists:prefix(DepsDir, D#dep.dir).
If deps_dir = ".", cwd = "/root", dependency name = "app"
then DepsDir = "/root/." and D#dep.dir = "/root/app" so
prefix fun returns false but should be true.
Dependency app will not be removed because of this.
proto_opts config option contains the compiler directive
that defines which proto compiler to use, also contains a
src_dirs entry that defines a list of locations for the
.proto files to be processed.
Add integration test that compiles .proto files from src
and from proto directory specified in separate rebar
config files
For protocol buffer files, when there were gpb options to alter the
module name with prefix or suffix, recompilation was not properly
detected. This is now fixed. (Issue #384).
Use the rebar_base_compiler's ability to specify both source and
target file names, to be able to also support prefixes.
This also introduces a call to gpb_compile:format_error, so the xref
recipe needs to be updated to ignore it, to avoid false errors.
The rebar_base_compiler:run/5 is an alternative to run/8, where
instead of source/target dirs and file name extensions, it takes
a list of tuples: [{SourceFileName, TargetFileName}], after the
idea by Tuncer Ayaz in discussion with Luis Rascão and me.
This is useful for situations where the target file name cannot be
expressed as only a new suffix or extension. For example the gpb
protocol buffer compiler can take an option to add a file name prefix
as well as a suffix.
As a result, the values passed around inside the internal functions in
rebar_base_compiler are either source file names (eg. when the run/4
function has been called), or items, which are two-tuples
{SourceFileName,TargetFileName} (when the run/7,8 or /5 functions have
been called).
Implemented, by moving upgrade functionality from install_upgrade.escript
to nodetool, which already supports both short and long names.
Make install_upgrade.escript as wrapper for nodetool for backward compatibility.
Spinning up a distributed Erlang node by running 'erl -name ct3' failed
due to FQDN issues. Hiro Asari from Travis-CI suggested to try out the
new container-based workers as a fix, and that one works as expected
because we get a proper FQDN. Therefore, make the switch to
container-based workers.
{recursive_cmds, []} was already documented as part of the core
rebar.config options that gets printed via 'rebar -h', but this wasn't
sufficiently informative. To fix this, explain the use of
recursive_cmds as part of the -r help string.
Reported-by: Stefan Strigler
In the rebar.config files for the gpb and protobuffs inttests, use the
{Name, Version} dependency form instead of {Name, Version, Source},
since the Source is not really applicable; the mocks are copied into
place by the proto_gpb_rt:files/0 and proto_protobuffs_rt:files/0.
Idea and suggestion by Tuncer Ayaz.
Installation of the gpb and protobuffs mocks, in inttest, is now done
using copy in proto_{gpb,protobuffs}_rt:files/0. Previously, rebar
prepare-deps was used, the dependencies had an rsync source with a
relative path back to the inttest directory. This eliminates a
dependency in inttest to rsync, instead relying on retest's
functionality to copy files and directories. Also, it eliminates
hidden knowledge about the directory layout that retest chooses.
Idea and suggestion by Tuncer Ayaz.
Since the dependency sources in the inttest rebar.config files are no
longer used, they are now changed back from rsync paths to git urls,
to serve as examples.
In inttest/proto_protobuffs, replace the external dependency to
erlang_protobuffs, a protocol buffer compiler, with a simple mock.
The mock provides enough of what is needed for inttest only,
which is to generate some dummy content, but with proper file names.
In inttest/proto_gpb, replace the external dependency to gpb, a
protocol buffer compiler, with a simple mock.
The mock provides enough of what is needed for inttest only,
which is to generate some dummy content, but with proper file names.
As a result, the increased timeout for the proto_gpb inttest should no
longer be needed (inttest/proto_gpb/retest.config), both since the
mock is now much faster to compile, and since any network bandwidth or
connectivity issues have now been eliminated.
* Refactor reltool version check to use vsn app key if ebin/reltool.app
exists.
OTP releases prior to R14 didn't install the app file, so we still
have to support getting the version string from the lib_dir path. If
you're using an R13B03 or R13B04 install that doesn't have version
strings in lib_dir paths (lib/reltool vs lib/reltool-0.5.3), we won't
be able to retrieve the version string. Given R13's age and that it's
unusual to have vsn-less lib_dir paths, this shouldn't be a problem.
* While at it, delete trailing white space.
This reverts commit 81063d33f0, reversing
changes made to 6584defdda.
This was reverted because it changed the gpb compiler to
not use rebar_base_compiler. That change was to add support for
target name prefixes, but it is better to add that support to
rebar_base_compiler.
