Several projects use an include path relative
to the project's root.
file:compile will look in three places for the include
files:
The current working directory
The directory where the module is being compiled
The directories given by the include option
* modify compiler interface to work on either application objects or
directories containing source files
* compile all sources in `src_dirs` to the application `ebin` dir and
all sources in `extra_src_dirs` to a directory mirroring it's
position in the app's `_build` directory. for example, `apps/foo/more`
would compile to `_build/default/lib/foo/more`
for `extra_src_dirs` in the root of a project with multiple
applications (so orphan directories that don't "belong" to an
application) compile to `_build/default/extras/more`
* copy directories specified in `extra_src_dirs` into the `_build`
directory so tools like `ct` and `xref` that expect source to be
in a particular location still work
* clean compiled artifacts from all `extra_src_dirs`
* alter `eunit`, `ct` and `cover` to work with the new directory
structure
* billions of new tests
The test works by using a parse transform that stamps modules with an
attribute as it runs them. It then compiles everything, loads the
module, and makes sure the stamps respect the defined order.
- Adding tests
- fixing use of set fetching to find repeated deps and prevent infinite
loops
On a circular loop rebar3 now fails with `{error, no_sort}`, which is
uncaught and should be handled to consider the issue fully fixed.
- Reworked the helpers for existing suites and expanded them
- Created a mock git resource module to test for its dependency fetching
- Added a test suite for dependency resolving with first checks for
common cases (https://gist.github.com/ferd/197cc5c0b85aae370436)
Left to do would include:
- Verify warnings
- Verify failures
- Verify dependency updates resolving