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

Direct selection of output directory (or file names) for OCaml compiler #7573

Closed
vicuna opened this issue Jun 29, 2017 · 10 comments
Closed

Direct selection of output directory (or file names) for OCaml compiler #7573

vicuna opened this issue Jun 29, 2017 · 10 comments

Comments

@vicuna
Copy link

vicuna commented Jun 29, 2017

Original bug ID: 7573
Reporter: @elfring
Status: acknowledged (set by @dra27 on 2017-06-29T10:15:54Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.03.0
Category: tools (ocaml{lex,yacc,dep,debug,...})
Duplicate of: #5890
Monitored by: @gasche

Bug description

The parameter “-o” is only supported for link operations by the tool “ocamlc” so far.
How do you think about to support the specification of additional names for output files which should be generated by the compilation?

Can the output folder ever be selected explicitly without depending on an adjustment of the working directory before invocation of this program?

@vicuna
Copy link
Author

vicuna commented Jun 29, 2017

Comment author: @dbuenzli

See #5890

@vicuna
Copy link
Author

vicuna commented Jun 29, 2017

Comment author: @dra27

I don't think you could ever use -o to change the names of files being compiled, unless specifying -o restricted one to compiling a single file at a time, which would be a bit weird.

Note the -impl and -intf options allow you to have custom file extensions (rather than .ml and .mli)

Questions about the desirability of new features will get more answers (or at least wider readership!) on either caml-list or discuss.ocaml.org (thanks @dbuenzli for identifying the cross-ref)

@vicuna
Copy link
Author

vicuna commented Jun 29, 2017

Comment author: @elfring

How will the support evolve for separate output directories with related software development tools for OCaml (besides the compiler)?

@vicuna
Copy link
Author

vicuna commented Jun 29, 2017

Comment author: @dbuenzli

@dra27 You can use -o to change the compilation unit name of a single .ml file.

@vicuna
Copy link
Author

vicuna commented Jun 29, 2017

Comment author: @elfring

May the compilation unit name refer to a folder which is different from the applied source file directory?

Since which software version is this functionality really sufficiently documented?

@vicuna
Copy link
Author

vicuna commented Jun 29, 2017

Comment author: @dbuenzli

Yes. The release notes say since 4.02. Though for ocamlopt the .o may not be generated in that directory in certain releases but I'm too lazy to find out. Maybe you can find the answer here da56cf6

@vicuna
Copy link
Author

vicuna commented Jul 1, 2017

Comment author: @dra27

@dbuenzli - oops, I either managed to read a really old manual, or just didn't read properly.

@elfring - the sentence "If the -c option is given, specify the name of the object file produced for the next source file that appears on the command line." in the documentation for "-o" covers it (see http://caml.inria.fr/pub/docs/manual-ocaml/comp.html#sec266)

Before 4.04.0, the -o option does not affect .c files when compiled with -c; after 4.04.0, ocamlopt -c -o foo bar.c works as long as you're only compiling source file (if you're compiling more than one source file, you get an error message)

The various commit messages and Mantis threads in #6475 suggest that my thinking was eventually agreed with - that having -c and -o for multiple .ml files is weird, but we have the behaviour for .ml files for backwards compatibility :o)

@vicuna
Copy link
Author

vicuna commented Jul 1, 2017

Comment author: @elfring

Do version constraints make it harder to represent the mentioned special cases in the manual accurately?

@elfring
Copy link

elfring commented Apr 15, 2019

I am still curious how affected software components can be improved also for this issue.

@github-actions
Copy link

github-actions bot commented May 7, 2020

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

2 participants