Stricter hygiene by default?

[ejgallego]

The nº 1 problem developers migrating to Dune face in Coq is one of having a dirty build tree:

> [Warning] File vernac.a is both generated by a rule and present in the source tree.
> As a result, the rule is currently ignored, however this will become an error in the future.
> Delete file vernac/vernac.a to get rid of this warning.

IMHO this warning is very confusing and is making new dune users lose a lot of time at first.

Should the warning be finally be made an error, and the message changed to something such as "your source tree is dirty, this is an error. Please remove any object files from it and try again".

[^^ the current wording is super bad I know, but you get the idea]

[ghost]

We should wait for a major release to change this warning into an error by default, though in the meantime we can add an option in the dune-project file to make it an error right now.

Alternatively, we could also make it an error when using (lang dune x) with x >= 1.8. Technically speaking it is a breaking change for the dune language, but it doesn't feel as bad as changing the behaviour for existing projects.

Thoughts?

[ejgallego]

Any of the two choices would be great for us; maybe the main question is: even today, does this use case makes sense?

Is there anyone relying on picking targets from the source tree for their project to build OK?

[ghost]

Originally the rule was silently ignored. i.e. (mode fallback) was assumed for all rules. There might be old projects that never added the (mode fallback) field and it doesn't feel right to break their build without notice.

[ejgallego]

I see, other kind of files may indeed be a problem [I was somehow only worried about ML object files]

I guess the warning has been there long enough but without testing it is hard to tell.

Thus in principle an option could be better, on the other hand that would introduce "option creep", I dunno.

[ghost]

I suggest that we make it an error from version 1.8 of the dune language then: we get the better behavior in newer projects and we don't introduce a new option. It is technically a breaking change in the language which means that upgrading from (lang dune x<1.8) to (lang dune y>=1.8) will sometimes break the build, however the warning as existed for long enough to make this acceptable. Additionally, it doesn't break the build of existing projects, which is the most important property.

[ejgallego]

Yup, it seems not pain-free but on the other hand would any project be affected it pretty easy to add the missing (mode fallback) entry.

[ghost]

Indeed, do you want to take a stab at implementing this? Something like Path.parent |> Path.drop_optional_build_context |> File_tree.find_dir t.file_tree |> File_tree.Dir.project |> Dune_project.dune_version should give you the version of the dune language in use.

[ejgallego]

I'll be happy to take care of this when my "working on Dune" slot comes, in practice that means in two weeks due to other deadlines so if someone feels like doing it before please do so!

[rgrinberg]

@ejgallego fixing this doesn't seem like a priority, so we're happy to let you tackle it. Will assign you.

[ghost]

I ended up doing that in #2068

[ejgallego]

Thanks for the update @diml, this was not far from the top of my todo list, sorry I didn't get to do it sooner.

[ghost]

No problem, it was quite natural to do as part of the other changes

[ejgallego]

Fixed by #2068 then.