Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocamlopt -shared -o creates by-products in a confusing place; documentation clarification welcome #6700

Closed
vicuna opened this issue Dec 9, 2014 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Dec 9, 2014

Original bug ID: 6700
Reporter: michipili
Status: acknowledged (set by @gasche on 2014-12-15T14:17:34Z)
Resolution: open
Priority: normal
Severity: minor
Platform: amd64
Category: documentation
Tags: junior_job
Monitored by: @gasche @hcarty

Bug 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
touch remote/module.ml
ocamlopt -shared -o module.cmxs remote/module.ml
ls -R

@vicuna
Copy link
Author

vicuna commented Dec 13, 2014

Comment author: @gasche

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?

@vicuna
Copy link
Author

vicuna commented Dec 15, 2014

Comment author: michipili

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

@vicuna
Copy link
Author

vicuna commented Dec 15, 2014

Comment author: @gasche

That seems sensible. If you or anyone is motivated to provide a better-worded patch, I'm ready to merge it.

https://github.com/ocaml/ocaml-manual/blob/trunk/manual/cmds/native.etex

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant