What exactly is the nature of these dependencies? Is it compile-time dependency (like your module can be called from schema module at compile time) or what?
hst337
josevalim
Creator of Elixir
We already track these dependencies as export dependencies. Although I need more information/context than the small example above to understand how you propose them to be used.
1
japhib
I’ve working on putting together a minimal umbrella app that reproduces the issue, but it’s not as straightforward as I thought 
In the process, I’m learning about compile-time dependencies. Maybe I’ll be able to improve our situation by fixing some of the compile-time dependencies in our project.
0
japhib
In the meantime, I do have a question – when running mix compile, it’s easy enough to see which files are getting compiled, with --verbose or --profile=time, but I can’t figure out how to tell why each file is getting recompiled. Is there any flag that would tell me something like that? For instance, something like this:
Module A being compiled because of changes
Module B being compiled because of runtime dependency on A
Module C being compiled because of compile-time dependency on B
...
Does such a compiler flag exist? If not, is there any chance you could point me to the general area in the Elixir codebase where I could add logs to try to deduce this myself?
(Note: I’m aware of mix xref trace and mix xref graph and have been using those tools to track down dependencies. However, even after changing certain dependencies from compile-time to run-time, certain files are still getting unexpectedly re-compiled on each change. The xref tools don’t show any dependencies between the files that would necessitate re-compilation, yet they’re getting recompiled anyway.)
0
axelson
Scenic Core Team
mix xref graph is the main tool for tracking down compile-time dependencies.
If you haven’t seen it https://medium.com/multiverse-tech/how-to-speed-up-your-elixir-compile-times-part-2-test-your-understanding-f6ff3de5eb5d is a great article that really walks you through what causes a compilation dependencies, including the surprising/tricky bit about transitivity.
Another tool you could try is DepViz, which I wrote when I encountered the same pain that you’re encountering: DepViz - A visual tool to understand inter-file dependencies - #5 by axelson
DepViz will give you a view similar to what you’re asking for. Imagine you’re trying to figure out why create_connection.ex is recompiled, you hover over that file:
From that you can see that there’s 16 files that will cause create_connection.ex to be recompiled. Of those, 3 are direct dependencies, but 15 of them are transitive dependencies via the compile-time dependency on command.ex
(side-note: something is not quite right in the math there! Probably the other two top-level files are being double-counted because there’s a comptile-time dependency loop)
If you want to dig further into how a specific file is reached via command.ex then first click on create_connection.ex, then click on a file (e.g. write_local_name.ex):
From that we can now see that there is the dependency chain:
create_connection.excommand.exwrite_local_name.ex
Where create_connection.ex depends on command.ex at compile-time, and command.ex depends on write_local_name.ex (at compile-time as indicated by the red dotted lines, although a run-time dependency between these two files would also create a transitive compile-time dependency for create_connection.ex).
I hope this helps you track down your compile-time dependencies!
4