Investigate use of order-only prerequisities in the Makefiles
Currently, we use order-only prerequisities to model runtime dependencies in a variety of cases (e.g. the REPL needs the frontend to properly function at runtime, even though it wouldn't be necessary for compilation [1]). While convenient, this makes certain rules hard/impossible to model:
- Building the libs requires a compiler that does not depend on the libs (otherwise we would have a cycle).
- Sometimes runtime dependencies only exist in certain configuration (e.g. the default one), thus raising the question whether they should or should not be declared as prerequisities in the Makefile.
- Not including runtime dependencies has the advantage of making distributions easier to package, since we could e.g. use
make --touch
to mark an entire target as prebuilt (without touching any runtime dependencies).
We should therefore investigate whether restructuring those rules would be good idea, both to keep the semantics of such prerequisities consistent and to make builds more efficient (currently we still use recursive make in few cases such as to enforce the ordering kernel -> tools, ideally we could model this dependency relation entirely using prerequisities).
An alternative pattern to using order-only prerequisities for runtime dependencies would be e.g. to use extra variables/lists to model variants of targets that include runtime dependencies and leave the original targets with only their compiletime dependencies. For example, a target like
$(ARTIFACT): $(COMPILE_DEP) | $(RUNTIME_DEP)
could be replaced with
$(ARTIFACT): $(COMPILE_DEP)
ARTIFACT_WITH_RUNTIME_DEPS = $(ARTIFACT) $(RUNTIME_DEP)
Note that this does not preclude the use of order-only prerequisites entirely, valid uses for these exist still, e.g. to depend on the creation of folders.
[1] The frontend here refers to the newly built frontend, not the frontend of the Curry compiler used to compile KiCS2.