Thanks a lot, David. the error message definitely needs to be restored. However, I do not feel comfortable with the way this is achieved, although I don't yet see a better way. What puzzles me is that I would like the dependencies we tell `make` about are real, accurate ones. Only if we do that, I think, will we be in a position where we can expect `make` to do its best job for us. I don't think writing dependenceis jsut for having one thing occur before another one is right (I am talking about the dependency of `sak` on `configu.status` this PR introduces. To me this is not a genuine, meaningful dependency. I investigated a bit and found out that `make` tries to build `sak` very eearly, even before it starts its real job, just because there is a dependency of `stdlib/StdlibModueles` on `sak` and `stdlib/StdlibModules` is included in the root Makefile. This dependency of `stdlib/StdlibModules` is written and documented in `Makefile.common` but I don't understand why exactly we need it? I am willing to open another PR to fix all this in a way that feels more straightforward to me, once we come to a good understanding.

David Allsopp (2022/06/24 00:50 -0700):

To build what, sorry?

I was actually wondering whether the dependency couldn't be refined a bit. Indeed, it's not the whole of `stdlib/StdlibModules` that requires `sak`, but only the definition of the `STDLIB_MODULES` variable.

Regarding this, I am wondering whether I didn't overlook something while merging `runtime/Makefile` in the root one. In `Makefile.common`, see the rule that says: ``` $(ROOTDIR)/%/sak$(EXE): $(MAKE) -C $(ROOTDIR)/$* sak$(EXE) ``` Shouldn't the recipe for this rule have been transformed into something like ``` $(MAKE) -C $(ROOTDIR) $*/sak$(EXE) ``` ? If I am correct, shall I open a dedicated PR or may I just force-push to trunk?