I've started a wiki page to document some of this discussion https://gitlab.haskell.org/ghc/ghc/wikis/Developing-Hadrian. We'll also need to deal with ouputs as well as inputs (dependencies) soon. Hence I've expanded a bit on my understanding of rule *outputs* and added the terms "vital input" and "vital output" (does it make sense? is there a better name here?). I've slightly changed the definition of "shallow dependencies" so that by definition it is a (minimal) subset of direct dependencies such that "no change in the shallow dependencies -> no change in the vial output" The important part to take away is that rules must:

• `need` all shallow dependencies.
• `produces` all vital outputs (excluding the rule target).

David E

Simon:

 

> Perhaps the remaining un-tracked dependencies will be fewer and easier to nail?

 

There are a few other cases where we `need` only a subset of direct dependencies that "cover" all others. For example, `setup-config` files produced when configuring a package are used to signal the completion of package configuration, which might produce a few other hard-to-predict files, such as “build/include/HsBaseConfig.h”.

 

I just realised that if one wants to have “hermetic builds”, where build commands are executed in a sandbox, then it is absolutely necessary to declare all direct dependencies without exception, because they will need to be made available in the sandbox for the build command to succeed.

 

David:

 

> Perhaps the best step forward is to simply silence the linting

> using `trackAllow ["//*.hi"]` for haskell object rules. Then

> I can continue tracking down other missing dependencies in

> Hadrian with fsatrace linting.

 

Yes, this looks like the best approach for now.

 

Cheers,

Andrey

-- 
David Eichmann, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England