|Anonymous | Login | Signup for a new account||2018-03-18 04:28 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007687||OCaml||compiler driver||public||2017-12-06 01:04||2018-03-08 18:33|
|Target Version||Fixed in Version|
|Summary||0007687: Deprecate the -thread and -vmthread flags|
|Description||The manual  mandates these flags to be used for any compilation unit one wants to compile against the thread or vmthread libraries which entails library specific compilation logic to be implemented by build systems.|
I turns out (see discussion in ) that these flags currently have no effect beyond altering the search path for includes and libraries which can perfectly be handled by the scheme(s) we have for compiling against a given library.
Further discussion in  seems to indicate there is no strong wish to change that state of affairs.
As such it would be good if
1) These flags are marked as deprecated in the compiler driver
2) The documentation is updated to no longer mandate these flags to be added on the cli when the threads or vmthread library are used.
 http://caml.inria.fr/pub/docs/manual-ocaml/libthreads.html [^]
 https://github.com/ocaml/ocaml/pull/1504 [^]
|Tags||No tags attached.|
Looked at this. The simplest thing is to make the flag -(vm)thread equivalent to -I +(vm)threads and remove Clflags.use_thread, Clflags.use_vmthread.
This introduces a tiny difference in the ordering of include directories:
- The -(vm)thread option adds the include directory +(vm)threads first (or last, do not recall at the moment), while -I +(vm)threads will add it in the order in which it appears with respect to the other -I options.
And a (small) breaking change:
- ppx processors may use Clflags.use_threads and Clflags.use_vmthreads to figure out the full list of include directories. (See GPR#1336)
Opinions? We can of course maintain Clflags.use_thread and Clflags.use_vmthread and simply do not use them in the compiler codebase to avoid the breaking change, but personally do not think it is worth the trouble.
nojebar I was actually rather thinking about all this being a purely documentation issue. Indicate that the flags are deprecated in `ocamlc -help` and remove the rules mentioned in the Threads chapter of the manual.
I don't think it's worth breaking all the build systems out there.
Agree. The command line options would be left as they are (suitably documented), but there is also the issue that the flags are exported via Clflags.use_vmthread and Clflags.use_thread to compiler-libs users, which is what my note was about.
In other words, there is a choice between doing: 1) "just documentation", and 2) "just documentation" + cleanup of compiler codebase (i.e. removal of Clflags.use_vmthread, Clflags.use_thread).
I would make a distinction between VM threads and system threads.
VM threads come with their own implementation of parts of the standard library (incl. stdlib.cma), so it felt important to me to tell users that all files of a VM-thread project should be compiled with -vmthread, so that they all agree on the standard library used. [ This said, it's only the implementations of some stdlib modules that change, not the interfaces, so maybe it's not that bad? ] For this reason, I'd keep the -vmthread flag documented and not deprecated until we get rid of VM threads altogether.
System threads, on the other hand, don't play tricks with the stdlib, so I'm OK with documenting -thread as not required and equivalent to -I +threads.
|2017-12-06 01:04||dbuenzli||New Issue|
|2017-12-06 14:30||nojebar||Note Added: 0018733|
|2017-12-06 15:24||dbuenzli||Note Added: 0018734|
|2017-12-06 15:32||nojebar||Note Added: 0018735|
|2017-12-20 17:11||xleroy||Note Added: 0018754|
|2017-12-20 17:11||xleroy||Status||new => acknowledged|
|2018-03-08 18:33||nojebar||Note Added: 0018937|
|Copyright © 2000 - 2011 MantisBT Group|