In general, hosted mode is assumed "by default" if the target
is not Xous. This allows packages to be built cleanly on command
lines that don't know to pass a --feature flag to specify a target.
However, an explicit "hosted" flag is still retained so that we
can confirm the build system intent. This saves us from the failure
mode that we thought we were building for target A, but accidentally
ommitted the flag, and instead we've been silently building for
"hosted" mode without any warning. The main consumer of the "hosted"
flag is now just the build.rs script inside of the utralib.
cargo debugging is so hard. If you're OK with it, I really would like gems like how to debug this code to be included as a comment in the source where you might look to fix such problems. Google turns up crap results when you try to search for these hints, and the results have been really unstable as well. I know such comments pollute the source code but it'll save a lot of time in the future trying to remember the trick to debug a tricky thing later on, I think.
Generate files in-memory (which is a cheap operation) and only write the
file to disk if it is different from the existing file.
This prevents rebuilds in the following circumstances:
1. When changing utralibs, an extra rebuild is always generated due to
the file being updated mid-build. This will no longer happen.
2. When switching targets, there will no longer be an unconditional
rebuild. This is because the feature flags are mixed in with the
package hash, and different builds use different feature flags.
3. When one svd file is updated, other variants of that feature flag are
no longer rebuilt. For example, when updating the Renode SVD,
Precursor DVT1 will not need to be rebuilt, since that has not
changed.
Changing a given SVD file will cause that target's version of utralib to
be rebuilt, and only that target's version.
Signed-off-by: Sean Cross <sean@xobs.io>
resurrecting some old hardware as an efuse testing target;
new hardware is too precious at the moment given the ridiculous
shortage of FPGAs on the market.
this is necessary because we need the full SVD path to generate
the whitelist of physical pages that can be addressed. Since the
SVD path is now domiciled in utralib, a file called "SVD_PATH"
is created in the target/ directory which contains the resolved
path to the SVD file given the abstract target/rev feature pair.
this fix makes it so that
1) you always get a correct build when the SVD spec is toggled
2) you don't always rebuild when nothing has changed
(2) is with the caveat that the no-change flag is only clean
after your second build (i.e. your third run will be fast).
I'm not quite sure why but I think it's because the "changes"
to the config file tracker are computed throughout the first
build and the second build still sees that file as recently
changed, so, it'll trigger a rebuild (could also just be
a race condition because the timestamp of the rebuild is
at the same second that the file was regenerated, so conservatively
you'd rebuild the next time).
Previously, the svd file was treated as an environment variable to
watch. Naturally this never changed, so an updated svd file never
triggered a rebuild.
Signed-off-by: Sean Cross <sean@xobs.io>
this cleans up some namespace issues when including
the utra crate which also refers to utra::generated::utra,
and there are CONST at the crate-level, and also functions
at the module-level which need disambiguation. By naming
the crate utra-lib this saves a bit of syntatic wrangling
at the top of every file.
