[jolmg]

Not familiar with Erlang, but from reading I imagine that rebar3 understands those `{% extends ... %}`, and uses them to determine what needs to be updated. With a Makefile, you'd express those dependencies in the Makefile rather than each file.

Although, one can probably write a Makefile such that it loops through each file, greps or otherwise obtains the `extends` and generates the Makefile rules that way.

[toast0]

> Although, one can probably write a Makefile such that it loops through each file, greps or otherwise obtains the `extends` and generates the Makefile rules that way.

You can do it with grep and what nots, but it gets icky fast. Much better is to have the compilers output dependency information while they're compiling, and use that. The compilers have to know the actual dependencies, because they're opening them, and reasonable compilers have options to save it for you.

[jolmg]

> have the compilers output dependency information while they're compiling, and use that.

It'd be moot after they've been compiled. You're saying compile to get the information to decide if you should compile.

[toast0]

The information is for the next invocation.

If you compiled it and it used these files and none of those changed, you don't need to compile it again.

When you add a new file, it clearly doesn't have an output file, so it needs to be compiled. Where it gets a little less clear is when you've got something that depends on all the input files --- if you just use the compiler's dependencies, when you add a new input file, Make (or whatever) wouldn't care, because last time it compiled (or linked), that file wasn't used, because it didn't exist.

So you still need some rules that are based on directory scans, if that's how you want to roll.