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
-o is ignored for C files #6475
Comments
Comment author: @whitequark I should add that ocamlbuild should be fixed as well when this issue is resolved. It currently uses mv to move the .o from the current directory. |
Comment author: @gasche whitequark, could you write a test case in the ocamlbuild testsuite to make sure your ocamlbuild patch works as expected? There already is some very light output-obj testing in internal.ml. |
Comment author: @whitequark I have attached a new patch that contains:
|
Comment author: @gasche I merged the (very nice!) patch, but in trunk only rather than in the stable branch. My reasoning is that other build systems may have workarounds for this issue (we had to fix ocamlbuild) which may break now that it is fixed. (We don't know yet whether there will be another minor release, but Damien seems to be thinking about it.) Thanks to all of you for the report and bugfixes. |
Comment author: @whitequark I believe this can be merged in stable, because the patch does not change the behavior without -o, and other buildsystems are unlikely to pass an option that does nothing. So the workarounds will still work. |
Comment author: @whitequark (In other words we did not have to fix ocamlbuild, I just thought it would be much cleaner.) |
Comment author: @gasche Okay, will merge in 4.02 at a later date. |
Comment author: @gasche Merged in 4.02. |
Comment author: @damiendoligez There is a problem with this change: it breaks (at least) ocamlnet because the ocamlnet config script does this:
And with this patch, the C compiler puts its output in The long-term solution is for users to be aware that the order of arguments is important and to write instead:
I wouldn't mind doing this in trunk and documenting it properly ("sets the name of the output file for the next source file, or for the whole compilation if it appears on the command line later than all sources files") but for 4.02 I think it's too much incompatibility, so we should roll back. We should also probably reset the -o argument as soon it has been used for one source file, since it doesn't make sense to overwrite a file you have just generated. Thoughts? |
Comment author: @whitequark No, I think that the current behavior is actually wrong. There is no reason whatsoever to set the output file name for one of the intermediate build products. Indeed, the -o option should always set the filename for the whole compilation. |
Comment author: @gasche I just reverted (4.02@15863) the 4.02 commit. The behavior in trunk is still problematic, so I'll revert it as well if don't converge on a solution. |
Comment author: @damiendoligez @whitequark, I thought we had decided it would be nice to be able to do: ocamlopt -c -o /tmp/foo.o foo.c -o /tmp/bar.cmx bar.ml Or maybe that's overkill because no build system will do that. In that case, we still want -o to work if there's only one source file and the -c option is also given. |
Comment author: @whitequark I think that's overkill and is very confusing. No other compiler in existence does that, and even few Unix tools do. Indeed; with -c, that would qualify as the end result of compilation. |
Comment author: nevor The commit seems to have been reverted after the merge into trunk. The current behavior (still) breaks library generation from mixed C/OCaml files as described by doligez. |
Comment author: @alainfrisch I'm raising the Severity, since this is an actual regression from the previous release. We should either revert the change or find a proper solution. |
Comment author: @alainfrisch I propose to revert this today, unless someone objects to it (or, better, fixes the issue). |
Comment author: @whitequark I object to reverting. Is it hard to make a change so that the name for the whole compilation is set? I would do it, but I am trying to move internationally right now, so a bit busy here. I can do it in about three days. |
Comment author: @alainfrisch
I don't know, I did not look at it. I only observe that the current behavior can introduce regression in the wild (concretely, at LexiFi, we had to fix on Makefile locally after synchronizing with trunk) and that it should be fixed before the release. I'll let Damien decide on what to do. |
Comment author: @whitequark Damien, any thought on this? I will be able to spend some time on this soon. |
Comment author: @damiendoligez What the compiler should do is clear:
What is less clear is what to do when More generally, you want to trigger an error instead of overwriting an output file that was just written by the same command. 4.03.0 will be released within one month, so you should propose a patch within the next few weeks. And make it as simple as possible, so we can be sure it doesn't break something else. |
Comment author: @whitequark Please see #464. |
Original bug ID: 6475
Reporter: @yallop
Assigned to: @whitequark
Status: resolved (set by @gasche on 2016-06-14T15:40:54Z)
Resolution: fixed
Priority: normal
Severity: major
Target version: 4.03.1+dev
Fixed in version: 4.04.0 +dev / +beta1 / +beta2
Category: ~DO NOT USE (was: OCaml general)
Tags: patch
Related to: #5890 #6218
Monitored by: @whitequark @gasche @hcarty
Bug description
The -o option is ignored when compiling C files, which makes it slightly awkward to write object files to a directory other than the current directory.
For example, the following command
ocamlc -c -o build/code.cmo src/code.ml
creates 'build/code.cmo' as expected, but the corresponding command for a C file
ocamlc -c -o build/code.o src/code.c
creates 'code.o' in the current directory.
File attachments
The text was updated successfully, but these errors were encountered: