Restore stronger check for overlapping libraries

[ghost]

Let's consider the following case:

• library a is part of the workspace
• a depends on b which is only installed
• b depends on c which is both installed and present in the workspace

before beta18, this was an error. In beta18 it isn't an error anymore, this allows in particular to lint Base without having to create a big workspace. However the new behavior is confusing for users, so we restore the pre-beta18 behavior by default and add an option allow_soft_conflicts to get the beta18 behavior.

[ghost]

I'm not entirely sure about the name allow_soft_conflicts, this is open to suggestions

[rgrinberg]

whitespace issues?

[ghost]

Oops

[rgrinberg]

I'm not so sure why it has to be an option on buildables. Shouldn't it be a workspace or a profile setting? For example it would be nice if building @lint would automatically set this.

[hcarty]

@diml Thank you! Pinning to your fork/branch fixes the simple a/b/c test case as well as the real project where I first ran into the issue.

In the real project with a more complicated nesting of code I now get the same error I would get in beta17 (names edited):

Error: Conflict between the following libaries:
- "a" in _build/default/b/a/src
- "a" in /home/hcarty/.opam/4.06.0/lib/a
    -> required by library "c" in /home/hcarty/.opam/4.06.0/lib/c
This is not allowed.

while in beta18 I'd just get a type error.

Ah, and there's a typo in the error message there (lib(r)aries).

[ghost]

Ah, and there's a typo in the error message there (lib(r)aries).

Thanks, it's fixed

[ghost]

I'm not so sure why it has to be an option on buildables. Shouldn't it be a workspace or a profile setting? For example it would be nice if building @lint would automatically set this.

@rgrinberg, possibly. Although even for @lint this is unlikely to happen. Base is a particular case. Additionally in the case of Base, it seems to me that we will almost always want this behavior, so it this information should be written once and for all in the jbuild file.

[hcarty]

Would allow_mixed_dependencies work for the option name?

[ghost]

I'm not sure mixed is the right term, it makes me think about allowing both local and external dependencies. But maybe allow_overlapping_dependencies.

[hcarty]

I like overlapping for this.

[ghost]

I updated the code