ferd
commented
4 years ago The dependencies are used to build the DAG, which is in turn used to propagate changes and timestamps across files. It is not used to define what needs to be compiled or when at this point in time, just to update all the non-artifact vertices in the graph and later allow proper file analysis. So if file A depends on B and B changes, we will update the last modified timestamp of A to be the same as B.
The actual scheduling and ordering of files to be built is handled in the needed_files/4 callback (as documented in http://rebar3.org/docs/extending/custom_compiler_modules/), which is where it is expected you do the analysis of the files:
%% do your own analysis aided by the graph to specify what needs re-compiling.
%% You can use this to add more or fewer files (i.e. compiler options changed),
%% and specify how to schedule their compilation. One thing we do here for
%% erlang files is look at the digraph to only rebuild files with newer
%% timestamps than their build artifacts (which are also in the DAG after the
%% first build) or those with compiler options that changed (the
%% compile_and_track callback lets you annotate artifacts)
needed_files(G, ["/path/to/all/files.erl", ...], [{".beam", "/path/to/ebin"}], AppInfo) ->
%% the returned files to build essentially specify a schedule and priority with special
%% option sets
%% Files that _must_ be built first like those in parse transforms, with
%% different build options
{{["/top/priority/files.erl"], CompilerOpts},
%% {Sequential, Parallel} build order for regular files, with shared
%% compiler options
{{["/path/to/file.erl", ...], ["other/files/mod.erl", ...]}, CompilerOpts}}.We do the same thing in rebar3_compiler_erl, and consider a broader set of changes. For example, we compare the timestamps of the build artifact to the source file that created it, but also the compiler options that were used for the build artifact with the current one (a file that hasn't been changed but whose compiler options have been modified needs to be recompiled as well).
I've been toying with a simpler sample app where I rewrite my blog engine to have the template files' changes tracked through the DAG, I'm hoping to have it ready some time this week.
leostera
seanhinde
Project
I'm building a plugin for caramel, which relies on the new module dependencies feature of custom compiler modules
Environment
Current behaviour
What I see at the moment is that the dependencies don't change the compilation order. I haven't dug too deeply, but here is my dependencies callback:
And the debug output:
So for file caradeps_b.ml I'm returning [caradeps_a.ml] as dependencies (because caradeps_b.ml tries to call a function in caradeps_a.ml), and caradeps_a.ml dependencies are [].
What I see is that rebar3 first tries to compile caradeps_b.ml, which correctly fails on the missing dependency
I also tried swapping the deps return values around to check my understanding - same result, caradeps_b.ml is tried first.
Expected behaviour
Dependencies are compiled first
Would be great to have another pair of eyes on this, thanks.