fix(ml-sources): check that a library is available before tracking it

[anmonteiro]

Since #10307, dune started allowing libraries to share the same name.

Thus, checking enabled_if isn't enough for libraries; dune now needs to check whether the library is available before tracking it in ml_sources.

addresses #10307 (comment)

[anmonteiro]

This diff is way better without whitespace https://github.com/ocaml/dune/pull/10355/files?w=1

[rgrinberg]

One issue with this PR is that it's introducing a library database look up before we're able to resolve the sources of a library. That now has the potential for cycles. E.g:

(rule
 (with-stdout-to foo "m_%{lib-available:bar"))
(library
 (name foo)
 (modules %{read:foo}))

It would be better to delay this availability check until the source is needed by somebody

[anmonteiro]

One issue with this PR is that it's introducing a library database look up before we're able to resolve the sources of a library. That now has the potential for cycles. E.g:

(rule
 (with-stdout-to foo "m_%{lib-available:bar"))
(library
 (name foo)
 (modules %{read:foo}))

It would be better to delay this availability check until the source is needed by somebody

This cycle is present even if I revert my diff. Are you suggesting that we're adding to it rather than causing it?

[anmonteiro]

I changed the implementation to delay querying Lib.DB.available_by_id until we query for modules_and_obj_dir. The implementation is fairly minimal, but it makes modules_and_obj_dir return a Memo.t and an extra Lib.DB.t argument, which make the diff a bit larger.

[anmonteiro]

@rgrinberg I think this is still waiting for another look.

[rgrinberg]

I'll try and take a look again this week