I had to change threads to threads.posix for this to compile dune. I think that's fine for dune, since we might rely on posix semantics. But I don't think that users are going to know to do this. How do we handle threads in this case?

vmthreads are deprecated in 4.08 so eventually this extra complexity will go away. In the meantime, I'm not sure what the best option is :/ We could add a special case for threads though it's not very satisfying. Otherwise we could try to detect by analysing the META file that threads is just an alias rather than a proper library. Or just document that when using this option one needs to use threads.posix rather than threads. My preference is for the last option.

My idea is to have the compilation context check if the feature is enabled (in the dune project file) before returning requires_compile. If the feature is disabled, it will simply use requires_link and generate Includes.t with this value.

Seems good to me.

It's a bit annoying to calculate the requires_compile if it isn't going to be used every time. Any ideas on how restructure the code to avoid this? I was thinking perhaps we could make a constructor of Compilation_context.t that consumes a Lib.Compile.t, and have requires_compile be lazy in Lib.Compile.t.

What about making requires_compile be lazy everywhere?

vmthreads are deprecated in 4.08 so eventually this extra complexity will go away. In the meantime, I'm not sure what the best option is

When vmthreads will go away, will threads and threads.posix just be aliases of each other in findlib? If so, then we might as well copy that option.

What about making requires_compile be lazy everywhere?

Will do that

When vmthreads will go away, will threads and threads.posix just be aliases of each other in findlib? If so, then we might as well copy that option.

I'm not sure yet, but possibly. Note that since we always set the mt_posix predicate, with dune threads is always an alias for threads.posix. Although I'm not sure how to take advantage of this fact without silently replacing threads by threads.posix in dependency lists, which doesn't feel right.

Although I'm not sure how to take advantage of this fact without silently replacing threads by threads.posix in dependency lists, which doesn't feel right.

What about changing the internal META for threads to alias threads to threads.posix?

In any case, since it's an experimental feature we can certainly just stick to documenting this limitation for now.

the internal META is only used when the one installed by findlib is not found, so it's pretty much never used when using opam. Sticking to documenting the limitation seems like the simplest solution to me as well, and it will make users aware of the issue, which might exist for other libraries.

Apart from the documentation, this is ready for review.

BTW, if we can indeed simplify requires_compile as suggested, then we should probably make requires_link lazy as in some cases it won't be needed at all and it is more expansive to compute.

Should we make requires_link lazy then? I'm pretty sure it's not needed when building a library.

Good point. Will make it lazy

Btw, should we rename this into something more descriptive? For example, no_transitive_deps?

I suppose, yeah. It's true that from the point of view of a user who doesn't know much about the low-level details of OCaml compilation, "include" might seem a bit abstract. Maybe no_implicit_transitive_deps to be even more precise?

@diml I renamed it. I wonder if it would be good to have this toggle instead:

(implicit_transitive_deps false)

Perhaps if we change the default in dune 2.0, it would be nice for users to go back to the old setting.

Good point, I agree with making it toggle.

Test case added and now it's a boolean valued option

Another case where this option is useful:

Set it in the workspace file and then try to build a duniverse. This will let you discover places where dependencies are imprecise.