Indirect recursion with AutoDeps

[jacereda]

I'm adapting my build to use multiple outputs in rules and --share. The problem I'm facing is that the .lib files associated with .dlls seem to be marked properly detected as writes on the first invocation but are detected as reads on subsequent invocations (assuming no exported symbol was changed).

When this happens, I think the code in

shake/src/Development/Shake/Command.hs

Line 317 in 99c5a7a

-- If something both reads and writes to a file, it isn't eligible to be an autodeps

should really do something like If something both reads and writes to a file or the file is an output of the rule, the file in question isn't eligible to be an autodeps.

How could the is an output of the rule be determined?

[ndmitchell]

I think a reasonable rule would be that outputs are just ignored by AutoDeps, since they never make sense. As to the outputs, there is a produces annotation, which modifies localProduces which can be grabbed from inside the Action monad.

I'm not sure if %> etc set the localProduces or not (I think maybe they must do since otherwise the history functions wouldn't work?), but even if they don't, you could add produces ["test.lib"] in your rule to avoid the recursion. Does that seem plausible?

[jacereda]

Neil Mitchell ***@***.***> writes:

I think a reasonable rule would be that outputs are just ignored by AutoDeps, since they never make sense. As to the outputs, there is a `produces` annotation, which modifies `localProduces` which can be grabbed from inside the `Action` monad. I'm not sure if `%>` etc set the `localProduces` or not (I think maybe they must do since otherwise the history functions wouldn't work?), but even if they don't, you could add `produces ["test.lib"]` in your rule to avoid the recursion. Does that seem plausible?

Sure, I'll take a look. I wasn't aware of `localProduces` and added a `DeclareOutputs` just to test, it seems to work fine. I'll try to write a `localProduces` solution and send a PR.