Thanks to @gasche and @silene for helping to find a better field name.
Following Rocq’s terminology I have settled on exports. I updated the proposal and significantly reworded it. I think it is made clearer by the new name itself.
At this point it would be nice if someone from the dune people could have a look at this to see if they agree with the plan, so that we can move on and let libraries with exports fields be released in the wild.
I’m not sure i understand this part. To me it feels like this doesn’t change the behaviour that we have now for the requires field, but the rest of the discussion feels like you want to change the behaviour.
Do you not want instead that hidden_libs be not transitive?
In the linking phase in OCaml >= 5.2, those hidden_libs are also all linked directly, which feels contrary to the goal of this proposal (as i understand it)
Maybe I’m confused about the goal and the way the semantics is written. Could there be a “goal” section that describe the goal you want to achieve?
No, that would lead to dune’s current broken mode of implicit_transitive_deps false.
You want the hidden_libs to be simply included with -H which is different from what we have now. That prevents you from using their definitions in some subtle way which I’m afraid is not really documented in the manual (at least not in the -H PR). But it’s not this proposal duty to explain it. You might be able to understand the behaviour by reading the RFC.
You always link against everything. If a library l privately uses libraries (requires) and you want to link against l you will have to link against these private libraries as well.
However you if compile against l you should not be able to compile your code against the definitions of these private libraries.
I think the first paragraph here achieves that as well as the usage section.
Wrt to backwards compatibility: suppose somebody publishes a new project with requires and exports. Won’t that break existing code that understands requires but not exports?
Maybe you can refine this? You start with library names and introduce ‘requires’. Might be clearer if you gave actual META file examples.
No because as mentioned here you should add your exports in requires.
However user code can be broken by moving to build them with a build system that moves to correct dependency compilation (like they would be broken by implicit_transitive_deps set to true).
What if I don’t? Seems fragile to me. Fwiw I’m not opposed to the general idea, just think it needs a little more work.
Then you do not abide by the proposal. It’s a MUST. I expect dune generated META files to do that automatically for you. If you write you META files manually, then be careful.
Could you be more precise ?
Fair question. Still working on it. In fact I think it’s quite a tricky issue. We’re adding this -H thing. That’s pretty significant for build systems.
Wrt “then you don’t abide by the proposal”. Well sure you could redefine anything and then say that. The point of backward compatible is you need not even know there is a proposal. But if I understand you, if stuff breaks your response would be “then you should upgrade”.
Do you mean this is how you should write your META files, or this is what your software should do at runtime?
The point of backward compatibility is that systems that are unaware of the proposal still work which is the case with the proposal.
That doesn’t mean that you can’t ask people who are aware of the proposal to make more work so that these systems still work (which is: in META files exports fields should be included in requires field).
Yes in the META files, I clarified that bit in the proposal.
I think I just gave an example to the contrary, no? A system that cannot handle new stuff that conforms to the proposal. “Still works” would be meaningless if it only meant “excluding the new stuff”.
The only example you gave is this and in this example the answer is: no, the backward compatibility story handles it.