It is a separate topic, but I find that very frustrating also. Typical scenario: A is a compile-time dependency of a lot of files B to Z, which themselves are not dependencies of anything. 1) Change A 2) `mix compile` => compiles A, B, C, ... Y, and then produces an error in Z. 3) Fix Z 4) `mix compile` => recompiles A, B, C, ...Y and finally Z. If there is still an error, goto 3. A-Y should already be compiled. I haven't doubled checked, but it is my impression that the compiler doesn't prioritize latest modified file either?
On Monday, 21 June 2021 at 11:08:26 UTC-4 José Valim wrote: > But if you mean that if 10 files need to be compiled, then 1 fails, then > all 10 have to be compiled again, then that's correct. There are compiler > passes that need to run on all modules, such as undefined function > warnings, so we can't save intermediate files without introducing > reasonably complex checkpoints. > > On Mon, Jun 21, 2021 at 5:06 PM José Valim <jose....@dashbit.co> wrote: > >> I can't reproduce it. I introduced a syntax error: >> >> ~/ML/livebook[jv-eval-compile]$ mix test >> Compiling 1 file (.ex) >> >> == Compilation error in file lib/livebook_cli.ex == >> ** (ArithmeticError) bad argument in arithmetic expression >> lib/livebook_cli.ex:1: (module) >> (stdlib 3.15) erl_eval.erl:685: :erl_eval.do_apply/6 >> >> Then I fixed it: >> >> ~/ML/livebook[jv-eval-compile *]$ mix test >> Compiling 1 file (.ex) >> >> ................................................................................................................................................. >> >> On Mon, Jun 21, 2021 at 5:03 PM Zach Daniel <zachary....@gmail.com> >> wrote: >> >>> This question may be tangentially related, but I'll bring it up here: >>> It seems that, even if it is just the last module that has to compile >>> that fails, nothing is cached/saved, and on subsequent compilations, the >>> entire application will need to be recompiled. I'm unsure if there are >>> technical limitations that cause that to be true, though. >>> >>> On Monday, June 21, 2021 at 10:01:56 AM UTC-4 Allen Madsen wrote: >>> >>>> +1 >>>> >>>> I've noticed mtime changes in some scenarios related to CI and docker, >>>> that causes things to be recompiled again even though there's no other >>>> change to the files. >>>> >>>> Allen Madsen >>>> http://www.allenmadsen.com >>>> >>>> >>>> On Mon, Jun 21, 2021 at 3:29 AM Marc-André Lafortune < >>>> marc-...@marc-andre.ca> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Jun 21, 2021 at 2:54 AM José Valim <jose....@dashbit.co> >>>>> wrote: >>>>> >>>>>> Hi Marc-André! >>>>>> >>>>>> There is no particular reason, this is a functionality that could be >>>>>> added. In particular we can continue checking the mtime and file size >>>>>> but >>>>>> compare the contents if the mtime changed but the file size is the same. >>>>>> >>>>> >>>>> Yep 👍 >>>>> >>>>> >>>>>> I also think we should update the mtime anyway, even if the hash is >>>>>> the same. WDYT? >>>>>> >>>>> >>>>> Yes, otherwise we might keep re-hashing the file over and over again. >>>>> >>>>> >>>>>> Feel free to open up an issue or, if you want to tackle it, even send >>>>>> a PR! >>>>>> >>>>> >>>>> Awesome. I'll check if I can come up with a PR in the next few days, >>>>> and if not I'll create an issue. >>>>> >>>>> Thanks. It's so awesome to get such quick feedback 💛 >>>>> >>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> On Mon, Jun 21, 2021 at 8:20 AM Marc-André Lafortune < >>>>>> marc-...@marc-andre.ca> wrote: >>>>>> >>>>>>> I'm a newbie, sorry if this has been asked before but I couldn't >>>>>>> find anything. >>>>>>> >>>>>>> Currently, elixir uses last modification dates to determine files >>>>>>> that need to be recompiled. >>>>>>> >>>>>>> ``` >>>>>>> $ mix compile >>>>>>> # ... >>>>>>> $ touch lib/some/file.ex >>>>>>> $ mix compile >>>>>>> Compiling <n> files (.ex) >>>>>>> ``` >>>>>>> >>>>>>> Could Elixir not verify that in addition to a modification time >>>>>>> change, that the actual text content has changed by comparing a hash of >>>>>>> it? >>>>>>> In the example above, the file `lib/some/file.ex` would be hashed a >>>>>>> second >>>>>>> time, but no recompilation would occur. >>>>>>> >>>>>>> Currently, many operations may change the last modification date >>>>>>> even if no content at all has changed: >>>>>>> * switch to a different branch, switch back >>>>>>> * do an interactive rebase: >>>>>>> - to rewrite a commit message, >>>>>>> - to reorder some commits >>>>>>> - to squash some commits together >>>>>>> - etc. >>>>>>> >>>>>>> While the content of the files does not change (at all) in these >>>>>>> examples, some very long recompilations may occur because elixir only >>>>>>> relies only on modification times and not on file hashes. >>>>>>> Hashing a file is orders of magnitude faster than compiling it, and >>>>>>> realizing that the potentially large number of compile-time >>>>>>> dependencies of >>>>>>> a given file do not need to be recompiled is infinitely faster than >>>>>>> recompiling them all for nothing. >>>>>>> >>>>>>> I am presuming that hash collisions are deemed so incredible >>>>>>> unlikely to be acceptable, but if not, then I'd ask the same question >>>>>>> but >>>>>>> with using the complete content of the source file instead of a hash of >>>>>>> it. >>>>>>> Copying a source file is again an order of magnitude faster than the >>>>>>> time >>>>>>> it takes to recompile it. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "elixir-lang-core" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to elixir-lang-co...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/e7a68d8d-0102-483d-a4ec-58849eb88ef6n%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/e7a68d8d-0102-483d-a4ec-58849eb88ef6n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "elixir-lang-core" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/elixir-lang-core/8-30JVn_8M0/unsubscribe >>>>>> . >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> elixir-lang-co...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L-_BRhadhXVckZ5TX4wLqgmxm-iuGHQr4M5Kdq4xM_1w%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L-_BRhadhXVckZ5TX4wLqgmxm-iuGHQr4M5Kdq4xM_1w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "elixir-lang-core" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to elixir-lang-co...@googlegroups.com. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/CADwvmaWP%2BccDF9QRdDfL8_B8fXuFXeFSL-fV0vLgOVqFH8LiHw%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CADwvmaWP%2BccDF9QRdDfL8_B8fXuFXeFSL-fV0vLgOVqFH8LiHw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elixir-lang-core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to elixir-lang-co...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/93dc87b6-6d61-43b9-81aa-5b740a525f15n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/93dc87b6-6d61-43b9-81aa-5b740a525f15n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c7dab775-9a6d-4f00-82af-a295eb5b68b5n%40googlegroups.com.
