Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007918OCamlcompiler driverpublic2019-02-12 11:442019-02-19 08:36
Reportercfranchini 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformOSGNU/Linux (Arch)OS Version
Product Version 
Target Version4.08.0+dev/beta1Fixed in Version 
Summary0007918: Non deleted object files on fatal warnings
DescriptionWhen 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

branch: trunk
commit: 07794568ebdb36d121051e8003cb9ccdd88d847d
verison: 4.09.0+dev0-2019-01-18

branch: 4.08
commit: a932c1a2364c26685686a1da0d2587c1e2652d1e
version: 4.08.0+dev4-2019-02-0
Steps To ReproduceRun the script checkspuriousobj.sh
TagsNo tags attached.
Attached Files? file icon checkspuriousobj.sh [^] (349 bytes) 2019-02-12 11:44

- Relationships

-  Notes
(0019591)
gasche (administrator)
2019-02-12 11:47

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.
(0019592)
cfranchini (reporter)
2019-02-12 11:55

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.
(0019593)
dim (developer)
2019-02-12 15:10

I would argue that make is the culprit here. A good build system should re-run actions that fail.
(0019594)
cfranchini (reporter)
2019-02-12 17:27
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.

(0019595)
dim (developer)
2019-02-13 09:08

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.
(0019596)
frisch (developer)
2019-02-14 10:09

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?
(0019597)
trefis (manager)
2019-02-14 10:58

Merlin will use .cmt(i) files for a few specific operations, but the majority of what it does is done using .cmi files.
(0019605)
gasche (administrator)
2019-02-15 18:59

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.
(0019606)
gasche (administrator)
2019-02-15 19:55

I bisected the issue, it first appeared during the following commit (the creation of driver/compile_common.ml)

  abc0b7e3edf3d4aeb9396e03e7d113f43818f18e
  https://github.com/ocaml/ocaml/commit/abc0b7e3edf3d4aeb9396e03e7d113f43818f18e [^]
(0019609)
gasche (administrator)
2019-02-19 08:36

I propose a fix in

  https://github.com/ocaml/ocaml/pull/2257 [^]

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker