| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This will at least display the script that failed with the stacktrace
before failing as usual, but without altering the return value.
This should make the common failure path more user-friendly without
breaking any existing behaviour that may have relied on the script file
working. If there's any unexpected side-effect, it will be visual only
rather than blocking full builds if ?ABORT were used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done through 3 main change groups:
- replacing `~s` by `~ts` in format strings, so that strings that
contain unicode are properly printed rather than crashing
- adding the `unicode` argument to all function of the `re` module to
ensure transformations on strings containing unicode data are valid
instead of crashing (see issue #1302)
- replacing `ec_cnv:to_binary/1` and `ec_cnv:to_list/1` with matching
functions in `rebar_utils`.
The last point has been done, rather than modifying and updating erlware
commons, because binary and list conversions can be a contentious
subject. For example, if what is being handled is actually bytes from a
given binary stream, then forcing a byte-oriented interpretation of the
data can corrupt it. As such, it does not appear safe to modify erlware
commons' conversion functions since it may not be safe for all its
users.
Instead, rebar3 reimplements a subset of them (only converting
atoms and chardata, ignoring numbers) with the explicit purpose of
handling unicode string data.
Tests were left as unchanged as possible. This may impact the ability to
run rebar3's own suites in a unicode path, but respects a principle of
least change for such a large patch.
|
| |
|
| |
|
|
|
|
|
|
| |
Includes improvments and function documentation for all modules (in
alphabetical order) up to rebar_core, and may have included more in
other modules as I saw fit to dig and understand more of the internals.
|
|\
| |
| | |
Always read REBAR_CONFIG env var when loading config
|
| | |
|
|/
|
|
| |
Some tricky changes in there but should be okay
|
|\
| |
| | |
lock file contains expected hash for pkg dependencies
|
| |
| |
| |
| |
| | |
This uses the env variable as a global store for variables. It's not the
cleanest thing, but it sounded nicer than pdicts.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reworks the version and hash printing in the lockfile to minimize
diff changes:
- the version is on its own line so that the locks are mostly the same
aside from the last line
- the hashes are each printed on one line with the package name for
simpler diffing too.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- the internal representation for package locks moves from `{Name, {pkg,
PkgName, Vsn}, Lvl}` to `{Name, {pkg, PkgName, Vsn, Hash}, Lvl}`
- the internal representation for packages moves from `{pkg, PkgName,
Vsn}` to `{pkg, PkgName, Vsn, Hash}`
- the hash can be `undefined`, meaning no check will be done
- no checking is done yet.
|
|/
|
|
|
| |
This adds support for their format both on the first read and when
looking for modifications to dependencies.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes to how hex or packages may work in the future will necessarily
bring changes to the format of lock files.
This commit adds an optional framing for future lock files of the form:
{Version, LockList}.
<Whatever consultable attributes>
This format is supported such as the LockList is the current lockfile
contents, and will never have more information than it currently does.
Attributes can be whatever and are currently undefined.
Rebar copies will be able to:
- Keep using the core locklist (which avoids breaking the last year or
so of community libraries using rebar3)
- Warn when it runs an outdated copy in comparison to the lock file
- Automatically rewrite lock files in the format it supports
- Augment or parse files in a version-specific manner.
This changes the usage interface slightly, but is backwards *and*
forwards compatible.
|
| |
|
| |
|
|
|
|
| |
Fixes compiling yaws, which has an .app.src.script file
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
fixes #172
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Removed separate compilers
Resolves apps to build
Finds avail deps before pulling/building
Includes relx
Simplifies build commands
|
| |
|
|
|
|
|
| |
* fix overlong lines
* where appropriate use %% instead of %
|
|
|
|
| |
We use namespaced_types option to choose between dict() and dict:dict() types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always-on recursive application of all rebar commands causes too many
issues. Recursive application is required for:
1. dealing with dependencies: get-deps, update-deps, and compile of deps
right after get-deps or update-deps
2. projects with a riak-like apps/ project structure and dev process
The vast majority of projects are not structured like riak. Therefore,
moving forward it's best to (by default) restrict recursive behavior to
dealing with deps. This commit does that and also adds command line and
rebar.config options for controlling or configuring recursion. Also, we
introduce two meta commands: prepare-deps (equivalent to rebar -r
get-deps compile) and refresh-deps (equivalent to rebar -r update-deps
compile). riak-like projects can extend the list of recursive commands
(to include 'eunit' and 'compile') by adding
{recursive_cmds, [eunit, compile]} to rebar.config.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|