-
Notifications
You must be signed in to change notification settings - Fork 118
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
Dependencies are unchanged, yet rule is rerun #813
Comments
If you run with lint enabled, it reports:
In particular, the file |
So the setting here is that Vivado is a shitty proprietary vendor product and all its file formats are shitty as well. My real build system is trying to do pretty much the same as this model:
My goal would be to be able to run actions further downstream (that depend only on the bitfile as input) without redoing the very slow second step. One subtlety is that the location (directory and file name) of the project file is baked into the project file itself during the generation from Tcl. So it's not even easy to generate a "pristine" project file without messing up the current state of an existing project file, when there is one. If writing to the project file from step 2 is not allowed without messing up Shake, what do you recommend for this situation? |
(Migrated from https://stackoverflow.com/q/69222477/477476 since my interpretation of Neil's comment is that he expects this to just be an output issue -- but it's not!)
I have a complicated setup where I generate a Vivado project file, and then run Vivado's synthesis tool to consume said project file and produce a bitfile. During this last step, Vivado updates some fields in the project file.
Below is a self-contained model of the situation:
What I would like to avoid is re-building
xpr
after a full build, since doing that invalidates all of Vivado's internal state, triggering a full re-synthesis. Note that none ofxpr
's dependencies change.Building
_build/bitfile
twice with--trace
shows the following:Note that this is not just a mis-reporting of the state of
build/xpr
! We can see from the output linevivadoXPR
that the rule to producebuild/xpr
really DOES get re-run!The text was updated successfully, but these errors were encountered: