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

Non deleted object files on fatal warnings #7918

Closed
vicuna opened this issue Feb 12, 2019 · 11 comments
Closed

Non deleted object files on fatal warnings #7918

vicuna opened this issue Feb 12, 2019 · 11 comments

Comments

@vicuna
Copy link

vicuna commented Feb 12, 2019

Original bug ID: 7918
Reporter: cfranchini
Status: confirmed (set by @gasche on 2019-02-15T17:59:31Z)
Resolution: open
Priority: normal
Severity: major
OS: GNU/Linux (Arch)
Target version: 4.08.0+dev/beta1/beta2
Category: compiler driver
Monitored by: @nojb @diml

Bug 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

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

branch: 4.08
commit: a932c1a
version: 4.08.0+dev4-2019-02-0

Steps to reproduce

Run the script checkspuriousobj.sh

File attachments

@vicuna
Copy link
Author

vicuna commented Feb 12, 2019

Comment author: @gasche

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.

@vicuna
Copy link
Author

vicuna commented Feb 12, 2019

Comment author: cfranchini

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.

@vicuna
Copy link
Author

vicuna commented Feb 12, 2019

Comment author: @diml

I would argue that make is the culprit here. A good build system should re-run actions that fail.

@vicuna
Copy link
Author

vicuna commented Feb 12, 2019

Comment author: cfranchini

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.

@vicuna
Copy link
Author

vicuna commented Feb 13, 2019

Comment author: @diml

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.

@vicuna
Copy link
Author

vicuna commented Feb 14, 2019

Comment author: @alainfrisch

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?

@vicuna
Copy link
Author

vicuna commented Feb 14, 2019

Comment author: @trefis

Merlin will use .cmt(i) files for a few specific operations, but the majority of what it does is done using .cmi files.

@vicuna
Copy link
Author

vicuna commented Feb 15, 2019

Comment author: @gasche

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.

@vicuna
Copy link
Author

vicuna commented Feb 15, 2019

Comment author: @gasche

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

abc0b7e
abc0b7e

@vicuna
Copy link
Author

vicuna commented Feb 19, 2019

Comment author: @gasche

I propose a fix in

#2257

@vicuna vicuna added this to the 4.08.0 milestone Mar 14, 2019
@alainfrisch
Copy link
Contributor

Fixed by #2257.

@vicuna vicuna added the bug label Mar 20, 2019
@nojb nojb modified the milestones: 4.08.0, 4.08 Mar 29, 2019
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

3 participants