The propagation was confusing source files and artifacts; the artifact
ordering was flipped, and the tagging non-mandatory (aside from as
edges), which made things hard to identify when plugins for compilers
are used.
This allows to do quicker re-compile option validation by not requiring
to access the disk and check all candidate erlang files for option
changes. This also opens up the way to compilers that produce more than
one artifact per file.
- Normalize path behaviour to always be "/" across versions
- Normalize port visibility behaviour to match input string when
appending
- restore rebar_utils function to avoid breaking random plugins that
peek into our libs for their stuff
- Support URIOpts equivalent and protocol-based overrides; the behaviour
there is not necessarily consistent across versions in terms of what
ports are returned (http_uri always returned a port but uri_string
only returns it if explicitly specified -- we choose the latter
behaviour on newer releases), but the calls work to ensure URI parsing
consistently works across versions
The latter judgement call is a bit of an odd one; for consistency we
could always mandate ports, but this would come at a performance penalty
when appending URL paths (i.e. when fetching packages).
The reason for this is that we standardize on the new uri_string
behaviour for path appending (if the port wasn't specified, we don't add
it), and with the http_uri rules, we need to do a kind of parsing round
that checks if the port was included or not to make it equivalent. This
is costly, and _not_ returning the port when it isn't specified lets us
do this transparently.
This allows to maintain backwards compat in older append functions, and
nobody aside from us currently uses the new rebar_uri module so we can
decide to introduce this potential inconsistency if we wish to.
Currently, we just write to ebin/ in the current working directory; this
implies that the source _should_ always be in the same subpath as the
ebin/ directory.
In the cases of utils like Mix, which store downloaded dependencies in
deps/ and artifacts in _build/, this may force more rebuild or less
caching that would be ideal.
This PR adds --outdir / -o as options to the bare compiler, which lets
the user specify another path, with a default kept to $CWD.
This moves the old DAG stuff out from the main code paths and
substitutes it with the new epp-based DAG work.
Also fixes previous work for integration tests:
- consider ptrans from erl_opts in app ordering
- display proper app compilation info messages due to reordering
While leaving the old one in place, prep the ground for new analysis
phases for the DAG work. The new DAG functions are added, but not hooked
in yet.
Fixes to the EPP handling have also been added due to issues in
resolving include_lib information
This commit is a transition point that makes some assumptions about new
callbacks for the compiler modules, which will likely not hold when it
comes to making epp be able to read and handle multiple applications at
once (so it can resolve parse transforms and behaviours across OTP
apps).
As such, a follow-up commit is going to be completing that one and
changing its API in incompatible ways; if you find this commit during a
bisect, it's probably not a good one in which to run a bisection.
Solves #2071, IPV6 support for proxy, by trying to resolve proxy
host name without specific IP address family. If it fails, it
attempts a different IP family, and in case that succeeds, it
sets up HTTP client profile to use IP family that worked.
When recompiling rebar3 itself, the path swaps and cleaning removes the
modules loaded from _build/bootstrap, but the VM still manages to
discover those in _build/prod from previous builds of the escript when
building the new escript, which causes weird failures when compilers get
modified between releases.
The fix is to just clear _build/prod as part of the init of the
bootstrap script, the same way we already clear _build/bootstrap.
The code was written at the time only one lockfile version was being
explicitly tagged (1.1.0), and all the other older ones were untagged.
In introducing the 1.2.0 format for external hashes, the current version
check still took place, but no provisions were made to explicitly check
between older or newer versions. As such, rebar3 would warn (prompting
people to upgrade) every time a lockfile on the 1.1.0 version (which is
likely over 99% of those in the wild as of today) would be encountered,
we'd prompt people to upgrade.
This patch introduces a constant for the list of supported tagged
versions for config/lock files, which allows to drop warnings when
rebar3 can transparently upgrade the lock file for the user.
It pre-supposes a potential "unsupported lock file" error could be added
in the future if a config format is not newer but in fact explicitly
deprecated. This isn't implemented but the current logic works towards
making that support possible.
- Vendor in hex_core at v0.6.8
- Rename checksum to inner_checksum and deprecate in favor of new outer_checksum key/val
- Change warn_vsn_once/0 to warn_vsn_once/1 so we can give a proper error message and
take appropriate action.
- Update rebar.lock to 1.2.0 format with continued support third-party
that still may make use of inner checksum via continued persistence of
inner checksums.
- Changed app info tuple (package representation) to support inner and
outer hashes for backwards compat support (see above)