| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the long run, we should do a better job of cleaning as we go, but
it's a bit tricky to do this without unnecessarily regenerating things
that haven't changed (particularly bitstreams). Probably requires
minor refactoring of the Makefile rules, perhaps with a holding pen
for things (like bitstreams) that we really do not want to regenerate
unless something has changed.
The current compromise is ugly in places, but works well enough, so
this is not a high priority.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the long run, once this stablizes into a normal set of Debian
packages with human maintainer(s), this business of constructing the
package changelog automatically will go away, but as long as we're
automating this, we need to be consistant in our automation.
|
|
build process cleanup.
|
|
new one.
Original design intent was that the build tree be created once then
left alone, but this turns out to be short-sighted: we really don't
want to have to re-synthesize all of the Verilog code just because
somebody added a new C file to the firmware.
|
|
|
|
|
|
Homebrew yet.
|
|
Undoubtedly doesn't work yet, and still needs doc, but perhaps now
ready for testing on build machine.
|
|
|
|
|
|
|
|
|
