Map `(re_export)` to `exports` field in `META` files

[nojb]

There is a proposal https://discuss.ocaml.org/t/proposal-a-new-exports-field-in-findlib-meta-files/13947/40 for a convention to extend the notion that we call (re_export) in Dune to general META files via a new field called exports. In order to play well with the ecosystem, Dune should map (re_export) to the exports file in META and vice-versa.

I suspect these aspects will become more relevant as time passes and (implicit_transitive_deps false) is adopted more widely, now that it is correctly implemented by -H.

[rgrinberg]

Seems reasonable. Out of curiousity, does anyone use this exports field in the META file yet?

[nojb]

Out of curiousity, does anyone use this exports field in the META file yet?

cc @dbuenzli ?

[dbuenzli]

I don't think it slipped into a release yet, but soon enough. Mainly to be able deprecate library names gracefully in -H aware build systems. E.g. here or there.

[nojb]

I took a stab at this one: #10831

[rgrinberg]

Probably too late for this now, but I think it would have been better to have a more specific field for deprecations. It's possible to tell the use they're using a deprecated name and that they should switch with this way.

[dbuenzli]

I don't think there's anything too late here.

exports + warning just happens to be one tool that can be used now for deprecations in a world with correct library dependencies (-H). Nothing prevents to provide other means in the future. E.g. a simple deprecated boolean flag could be added to signify that exports are the replacement libraries.

But note that exports, in a world with correct library dependencies, is useful beyond that. For example to devise meta libraries, or to automatically export a library you are enhancing, to trim your users's list of library dependencies, etc.