Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007687OCamlcompiler driverpublic2017-12-06 01:042018-09-10 18:09
Assigned Tonojebar 
PlatformOSOS Version
Product Version4.06.0 
Target Version4.07.0+dev/beta2/rc1/rc2Fixed in Version 
Summary0007687: Deprecate the -thread and -vmthread flags
DescriptionThe manual [0] 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 [1]) 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 [1] 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.

[0] [^]
[1] [^]
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
nojebar (developer)
2017-12-06 14:30

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.
dbuenzli (reporter)
2017-12-06 15:24

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.
nojebar (developer)
2017-12-06 15:32

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).
xleroy (administrator)
2017-12-20 17:11

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.
nojebar (developer)
2018-03-08 18:33 [^]
gasche (administrator)
2018-04-17 15:55

I hit an issue recently where a program didn't link correctly because the `-thread` option was not passed to *ocamlfind*. I think it's fine to deprecate the -thread option of the compiler, but we may live with it in the ocamlfind-world for the time being.
dbuenzli (reporter)
2018-09-10 18:09

This PR deprecates vmthread [^]

- Issue History
Date Modified Username Field Change
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
2018-04-17 12:55 nojebar Status acknowledged => resolved
2018-04-17 12:55 nojebar Resolution open => fixed
2018-04-17 12:55 nojebar Assigned To => nojebar
2018-04-17 12:56 nojebar Target Version => 4.07.0+dev/beta2/rc1/rc2
2018-04-17 15:55 gasche Note Added: 0019040
2018-09-10 18:09 dbuenzli Note Added: 0019354

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker