schnittchen
Hi,
I’m trying to track down why my testing experience is such a pain because there’s always many files being compiled… I’ve used the inotify trick from https://milhouse.dev/2016/08/11/understanding-elixir-recompilation/ to see which files these are (is there a simpler way?) and tried to understand from mix xref why those files were compiled.
So there’s runtime, compile time and exports dependencies, I learned from mix help xref. So when I do a trivial change like adding a newline in a source file, only compile time dependencies should trigger a recompile.
If I change file A, all files having a (transitive) compile time dependency on A would need to be recompiled.
This lead me to use mix xref graph --label compile --only-direct because my reasoning is that this would show me all non-transitive compile time dependencies, and I should be able to traverse from the changed file to every compiled file via a graph node connection in the output of this command.
Here’s a snippet from the output, the email.ex file has only one dependency shown.
lib/my_app/email.ex
└── lib/my_app/views/mailer_view.ex (compile)
The email file was recompiled when I made a trivial change in a file which, according to mix xref (with the invocation above), was not connected at all to the email file.
I must have some misconception here.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #ai
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming











First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
NobbZ
If A depends on B at compiletime, then any transitive runtime dependency of B is a compiletime dependency of A. As As compiletime is Bs runtime.
Most Liked
schnittchen
Thanks for the advice, I quickly found the culprit:
I had compile time dependencies from the router to two controllers. Because those controllers had a transitive run time dependency back to the router (redirects using route helpers) and from there to every other controller, changing any controller required the router to be recompiled.
The fix:
simply because now the fully qualified module name of the controller it no longer present in the router.
Two other things I did/tried:
in the
project/0callback of the MixFile, which made the effective dependency chain more obvious.I also tried setting
not only in dev mode, but in test mode as well, assuming that plug initialization would otherwise happen at compile time and that that would also be the case for the controllers being routed to (since they are plugs as well), but I was wrong here, the default
:compiledoes not make all controllers compile time dependencies of the router.schnittchen
I got tired of analyzing the output of
mix xrefso I wrote a thing… If you run into this problem please check out GitHub - schnittchen/why_did_recompile · GitHub and help me improve itaxelson
Have you given DepViz a try?
I spoke about it at Code BEAM BR last year (in english): https://www.codebeambr.com/video/12
That is not quite accurate, an
aliaswill only cause a run-time dependency. However, compile-time dependencies are transitive so ifA->compile-time->BandB->run-time->C, then whenCchanges,Awill need to be recompiled.Last Post!
riebeekn
Was revisiting this a bit today and realized I forgot to mention that in addition to the sugggestions above we found adding GitHub - sasa1977/boundary: Manage and restrain cross-module dependencies in Elixir projects · GitHub to be super helpful. It helped surface some poorly defined boundaries we had going on.