|Anonymous | Login | Signup for a new account||2019-02-22 21:15 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007918||OCaml||compiler driver||public||2019-02-12 11:44||2019-02-19 08:36|
|Platform||OS||GNU/Linux (Arch)||OS Version|
|Target Version||4.08.0+dev/beta1||Fixed in Version|
|Summary||0007918: Non deleted object files on fatal warnings|
|Description||When compilation of a module failed because of warnings, the generated|
object files are not removed. I attached a script that test just one
case - I didn't do exhaustive testing.
Tested on GNU/Linux (Arch) with the two following versions
|Steps To Reproduce||Run the script checkspuriousobj.sh|
|Tags||No tags attached.|
|Attached Files||checkspuriousobj.sh [^] (349 bytes) 2019-02-12 11:44|
|Is this not a reasonable behavior? If the .cmo file is valid, keeping it on the disk sounds useful. For example, I think that the fact that .cmi files stay on the disk even if later code generation files is useful for Merlin.|
No, it's not reasonable.
I type make once, it failed, if I type make again, it succeed. That's how I spotted the bug. That behavior will break all working Makefile in the Earth.
|I would argue that make is the culprit here. A good build system should re-run actions that fail.|
edited on: 2019-02-12 17:35
>I would argue that make is the culprit here.
We're talking about the program which builds gcc, linux, bash, emacs, ocaml, ... I'm sure it's behavior is the correct one.
>A good build system should re-run actions that fail.
[striked]I disagree, and I'm sure that a lot of people would agree with me. (Just to be sure: it's not sarcasm, is it?)[/striked]
edit: I was misunderstanding your second statement. It's not how make works.
|That's the idea; because make is very simple, individual commands have to be more sophisticated so that builds using make behave correctly. That doesn't feel completely right.|
Please let's stay focused here on what OCaml should do, not what a good build system should be. make is still used quite a bit (to build OCaml itself for instance) and we should not break existing workflows. Assuming the described behavior is a change in recent versions, I'm in favor of going back to the previous behavior.
If needed, one could add a command-line flag to control the behavior. But:
> If the .cmo file is valid, keeping it on the disk sounds useful. For example, I think that the fact that .cmi files stay on the disk even if later code generation files is useful for Merlin.
.cmt/.cmti files should certainly be kept even in case of errors, and they contain all the information (.cmti files "include" the .cmi information as is). Doesn't Merlin use these files?
|Merlin will use .cmt(i) files for a few specific operations, but the majority of what it does is done using .cmi files.|
|I hadn't realized while reading the original report that the described behavior was specific to non-released versions of OCaml, and that 4.07 behaves differently. This indeed sounds like a regression to be fixed.|
I bisected the issue, it first appeared during the following commit (the creation of driver/compile_common.ml)
I propose a fix in
|2019-02-12 11:44||cfranchini||New Issue|
|2019-02-12 11:44||cfranchini||File Added: checkspuriousobj.sh|
|2019-02-12 11:47||gasche||Note Added: 0019591|
|2019-02-12 11:47||gasche||Status||new => feedback|
|2019-02-12 11:55||cfranchini||Note Added: 0019592|
|2019-02-12 11:55||cfranchini||Status||feedback => new|
|2019-02-12 15:10||dim||Note Added: 0019593|
|2019-02-12 17:27||cfranchini||Note Added: 0019594|
|2019-02-12 17:35||cfranchini||Note Edited: 0019594||View Revisions|
|2019-02-13 09:08||dim||Note Added: 0019595|
|2019-02-14 10:09||frisch||Note Added: 0019596|
|2019-02-14 10:58||trefis||Note Added: 0019597|
|2019-02-14 18:50||frisch||Target Version||=> 4.08.0+dev/beta1|
|2019-02-15 18:59||gasche||Note Added: 0019605|
|2019-02-15 18:59||gasche||Status||new => confirmed|
|2019-02-15 19:55||gasche||Note Added: 0019606|
|2019-02-19 08:36||gasche||Note Added: 0019609|
|Copyright © 2000 - 2011 MantisBT Group|