I believe this is only going to be a problem if you have distinct rules for the various files produced by the compiler, one rule for the .cmi and another one for the .cmx, to take the more realistic example, and that you have several rules producing the same .cmi file (because you have some .mli files - I’m leaving aside the case where you want to compile both in native and bytecode form). Then if you ever only mention in the Makefile the .cmi files corresponding to the .mli files and explicit their dependencies, I believe you are perfectly fine (there is a simple dependency tree then). And since you should not have more than a very few .mli files that’s not very verbose to declare those relationships explicitly.
I do not see what no-alias-deps or opaque options can break in the model I just described.
It feels quite strange to have to prove that one can compile a project with make, when most of projects have been compiled with make just fine before ocaml-specific build tools become fashionable. Especially when some of them can’t handle parallel compilation at all or require complex setup as soon as one venture outside of the realm of student projects (see for yourself the doc about integration with the basic pkg-config).
I totally believe that ocaml-specific builder are better at compiling ocaml libs and programs, but that’s not the only thing a build system have to do. First it has to build other things, it has to link the result of compilation together, sometime in non-trivial ways, and it has to use ue parts of the outside system as well (libraries, tools). This is where makefiles shines.
Of course makefiles will break at time. But so do any build system, even the most theoretically robust one, since what breaks them is usually the interaction with the rest of the system not the compilation per se. For instance, it is to find the proper version of a library, or to run the proper script to generate some code file, or to compile some source code twice, once with some preprocessor and another one without, etc… The few I know about OCaml specific build tools I’ve learn by debugging others build script, so I know they can break too
In a typical project, one will want to compile some OCaml to machine code, some C, some OCaml to JS, will want to preprocess source files with some program beforehand in some cases but not all, generate some data files using some scripts, maybe also generate some source code files, and so on. No build tools will make this simple or robust, but at least makefiles will make it possible in a way that will be rather easy to adapt later on.
Let’s be honest: ocaml-specific build tools are great in a teaching environment, as they allow to cut down on system administration and file types shenanigans and go straight to the business of teaching computer science. This is a noble purpose. But the same I wouldn’t recommend to use ocaml-top as an editor outside of education, I wouldn’t recommend using an ocaml specific build tool.
But anyway, there is no point to argue because the trend is clear. Soon nobody will ever remember that there was a day when software had to be build at all, as this will only occur in some deep datacenter our dumb terminals will be sending all source code to.