Change Vivado project not to be order only dep

[Lucas-KB]

Fixes #423 by making the Vivado project a normal dependency of the other targets to ensure synthesis and implementation are rerun if a source file is updated.

[craigjb]

I'm also interested in this PR for FuseSoC. It seems like changes to verilog source files aren't triggering a build. I have to pass --clean to fusesoc run ... every time. The source file in this case is coming from a generator (not cached).

[olofk]

AFAIR I had to make the project file an order-only dep because it kept getting updated by Vivado which meant that everything that depended on the XPR got unconditionally rebuilt even if nothing changed. Looking at it now, however I see that the current logic doesn't really make sense. Maybe we can change the project generation script to write out a marker file and use that instead of the xpr to track when we need to rebuild?

[Lucas-KB]

That makes sense.

When I tested this before, I beleive that the only thing that depended on the XPR file was the synthesis and implementation runs, but those runs check wheather or not they are complete before running. So, in practice, if nothing changed, nothing would be run.

On the other hand, in case something else depends on the XPR file, that recipe would be run again.

Your solution of adding a marker file seems good.

[nicorum]

AFAIR I had to make the project file an order-only dep because it kept getting updated by Vivado which meant that everything that depended on the XPR got unconditionally rebuilt even if nothing changed. Looking at it now, however I see that the current logic doesn't really make sense. Maybe we can change the project generation script to write out a marker file and use that instead of the xpr to track when we need to rebuild?

I think this is more of a dependency issue. The xpr shouldn’t be rebuilt by Make at all if its dependencies don’t change. I also can’t reproduce this problem with the patch.
Perhaps fusesoc/edalize updated the timestamps of unmodified dependency files in an earlier version?

If there are file types that don’t affect the xpr, they could also simply be set as dependencies of the other targets instead of the xpr. (Maybe just TCL scripts for the XPR?)

[Lucas-KB]

I am not sure I understand everything you said.

I think this is more of a dependency issue. The xpr shouldn’t be rebuilt by Make at all if its dependencies don’t change.

That part is ok to me.

I also can’t reproduce this problem with the patch. Perhaps fusesoc/edalize updated the timestamps of unmodified dependency files in an earlier version?

What did you try to reproduce? The idea of the patch is to ensure the synthesis and implementation are rerun every time a source file is changed. The thing is, the current behavior is to remake the project file every time any source file changes.

If there are file types that don’t affect the xpr, they could also simply be set as dependencies of the other targets instead of the xpr. (Maybe just TCL scripts for the XPR?)

That could be a solution, but maybe we would have problems with xci and bd files. Not sure about this.

[nicorum]

What did you try to reproduce? The idea of the patch is to ensure the synthesis and implementation are rerun every time a source file is changed. The thing is, the current behavior is to remake the project file every time any source file changes.

I've been trying to understand oflofk's reasoning behind using order-only dep. He said that xpr gets updated even if nothing changes. But that's exactly what Make isn't supposed to do. And that didn't happen to me either with your patch. Or am I misunderstanding something here?

That could be a solution, but maybe we would have problems with xci and bd files. Not sure about this.

Yepp. The question is what dependencies the XPR file should actually have. And since Vivado is a black box to us, it’s pretty hard to figure that out. But we would have the same problem with the marker file. At some point, we have to decide which file changes trigger an update to the XPR file.

But I also wonder if that isn't a bit of over-optimization. At the risk of overlooking something.
The current situation at least has the advantage that it consistently doesn't work without “--clean”. In the worst case, that then depends on a few corner cases.