|Anonymous | Login | Signup for a new account||2017-03-26 13:12 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006700||OCaml||documentation||public||2014-12-09 20:15||2017-03-15 13:56|
|Target Version||Fixed in Version|
|Summary||0006700: ocamlopt -shared -o creates by-products in a confusing place; documentation clarification welcome|
|Description||When I run ocamlopt -shared and use -o to arrange to that the output file is not|
in the same directory as the source file, I see that by-products (*.o and *.cmi)
are stored along the source file.
It is expected that these by products are stored in the same directory as the file given as argument to the -o option. Indeed,
1. This is the behaviour of the compiler when producing a cmi as a a by-product
of a cmo file.
2. The sources can sit on a read-only media and the user guarantees that the
path used with the -o file is writeable.
3. Makefiles using the objdir-system¹ to store object files in a directory
distinct from the sources are easier to use if no object file is created
in the source directory.
¹: esp BSD Owl (https://github.com/michipili/bsdowl/wiki/DevelopOCamlSoftware [^])
|Steps To Reproduce||mkdir remote|
ocamlopt -shared -o module.cmxs remote/module.ml
This behavior is actually consistent with the way other compilation command work, such as when you ask to produce a bytecode executable from a source file (or several source files) directly:
ocamlc -o foo remote/module.ml
will first compile module.ml into a module.cmo (choosing to produce the compiled files in remote/), and then link the produced .cmo into a bytecode executable. Notice the difference with the two-step process
ocamlc -o module.cmo -c remote/module.ml
ocamlc -o foo module.cmo
which produces everything in the current module -- and has the ability to say so explicitly. In the same way you can produce your .cmxs as follows:
ocamlopt -o module.cmx -c remote/module.ml
ocamlopt -shared -o module.cmxs module.cmx
and no byproduct will be stored in remote/.
I'm worried by the idea of changing the default behavior in this use-case (the risk of breaking other build scripts seems important). Could you not use the more precise two-step process instead?
Thank you for your feedback. Using the more precise two-step procedure is of course feasible and there is no need to change ocaml behaviour.
Looking at the official documentation¹, I could not deduce properly how to prepare dynlink native plugins. Maybe I overlooked something, maybe the description of the -shared flag could be enhanced by using a stance similar to the one used for the -a flag:
> Build a library (.cmxa and .a/.lib files) with the object files (.cmx and .o/.obj files) given on the command line, instead of linking them into an executable file. The name of the library must be set with the -o option.
In its current phrasing, the description of the -shared flag misses two important features present in the snippet above:
- explictly listing .cmx files as valid input
- the [Build… instead of linking them into an executable.]
In my opinion, using a similar wording to describe the -shared and -a flags would clarify the manual. But this is just my opinion! :)
¹ http://caml.inria.fr/pub/docs/manual-ocaml-4.02/native.html [^]
That seems sensible. If you or anyone is motivated to provide a better-worded patch, I'm ready to merge it.
|2014-12-09 20:15||michipili||New Issue|
|2014-12-14 00:26||gasche||Note Added: 0012804|
|2014-12-14 00:26||gasche||Status||new => feedback|
|2014-12-15 11:27||michipili||Note Added: 0012820|
|2014-12-15 11:27||michipili||Status||feedback => new|
|2014-12-15 15:16||gasche||Note Added: 0012827|
|2014-12-15 15:16||gasche||Tag Attached: junior_job|
|2014-12-15 15:17||gasche||Severity||minor => text|
|2014-12-15 15:17||gasche||Status||new => acknowledged|
|2014-12-15 15:17||gasche||Category||OCaml general => OCaml documentation|
|2014-12-15 15:17||gasche||OS||FreeBSD =>|
|2014-12-15 15:17||gasche||OS Version||10.1 =>|
|2014-12-15 15:17||gasche||Product Version||4.02.1 =>|
|2014-12-15 15:17||gasche||Summary||ocamlopt -shared -o creates by-products in the wrong directory => ocamlopt -shared -o creates by-products in a confusing place; documentation clarification welcome|
|2015-01-13 23:03||doligez||Severity||text => minor|
|2015-01-13 23:03||doligez||Target Version||=> 4.03.0+dev / +beta1|
|2016-04-18 15:03||doligez||Target Version||4.03.0+dev / +beta1 => 4.03.1+dev|
|2017-02-16 14:01||doligez||Target Version||4.03.1+dev => undecided|
|2017-02-23 16:35||doligez||Category||OCaml documentation => Documentation|
|2017-02-23 16:44||doligez||Category||Documentation => documentation|
|2017-03-15 13:56||doligez||Target Version||undecided =>|
|Copyright © 2000 - 2011 MantisBT Group|