Do you have any pointers to those?
A lot of discussion already happened here on the proposal and may shed light on other people’s objections.
Personally, I had some hand-wavy philosophical objections based on the Unix-ey philosophy that the compiler should do one thing and do it well rather than getting into the business of tracking package dependencies.
But since then, I have read the RFC several times and I’m getting convinced that this has been thought through well and could be a valuable change - particularly for people who use the repl a lot - maybe I will become one of those people if this goes through.
I could not come up with any concrete examples of where this additional responsibility of the compiler constrains its flexibility within the limited use-cases that I have.
Only trivial things stick out to me, but don’t seem like they’re worth worrying about:
- If my program depends on
foo.cmxa(a third-party library I can’t change), which in turn says it depends onbar.cmxa, I cannot simply replacebar.cmxawithbaz.cmxain my build rules, even if it offers the same functionality, just because the name is stored inlib_requires : string listoffoo.cmxa- not a big deal, I can justmv baz.cmxa bar.cmxa - Similarly, in the above situation, I cannot instead of
bar.cmxaprovide a re-packaged split of the modules in saybaz1.cmxaandbaz2.cmxaas a replacement - again, you can probably work around this by naming one of the twobaz’s tobarand using the other as an additional-requires - This business of
-requires LIBadding the location ofLIBto both the includes (compilation) and linking phases seems like it makes the expected physical layout a little more rigid, e.g. if the directory forfoo.cmxacontainedx.mlithat I wanted hidden for compilation purposes, I kind of explicitly have to make sure they’re not co-located - but this is something that (probably)ocamlfindalready does, anddunealso, so is in practice not a big deal either