This is the weirdest damn thing. All the crates say 0.4.19 as
the chrono version, but the actual version in the lockfile
is 0.4.33. And there isn't an error about it?
Anyways, this update the pins to reflect what's in the lockfile.
The kernel and loader may need to use a different target, particularly
in the case of Precursor where the kernel and loader need an OS of
`none`.
Signed-off-by: Sean Cross <sean@xobs.io>
The problem is the original way of specifying crates for remote
download is the same that Rust uses to specify a version of a crate
(e.g. the @ symbol), and so I could not differentiate between the
two cases.
Switch to using a ^ symbol for remote download crates. Hopefully
that doesn't have conflicts??
this has become necessary because with the inclusion of a version
number in a crate name, rustc always consults the on-line index on
every build (even when it's not necessary), which can double the
build time. Using --offline reduces that thrashing.
this is because we are keeping an older version around
for a legacy ed25519 depedency, so we have to fully
specify which sha2 we want build as our server
A BinaryFile was previously identified only by its path,
thus if a bianry file represented an app rather than a service,
there was no information that could go in the manifest for the gam.
This let's one optionally specify a name for a BinaryFile.
passing this flag causes the loader to print debug output.
This slows down the loading process but gives you some visibility
into what's going on (maybe also an idea for the future to add
VDBG flags for verbosity, they exist in the code but not exposed
as command line options).
This creates:
1) An `xtask' command that allows someone to compile individual apps
without compiling the entire image (note that this is required because
xtask generates files that contain gam context names, and if you just
do a regular `cargo build' building the app will fail)
2) A python file app_server.py that acts as a server to give the
app-loader a list of the apps and actually send it the
3) A basic UX that allows app-loader to set the server, get the list
of apps, and load apps.
Currently, this mostly works, except that there is some random
`ShareViolation' when the app-loader loads the app.
When the user selects App Loader from the app menu, a new menu shows
up that displays the currently loaded apps (in the future this will
contain options to add/remove apps as well). This is a much more sane
approach than whatever I was doing before because it requires minimal
changes to the rest of the source tree (I had to change xtask so that
it would replace -'s with _'s in constant names so that I could name
my app app-loader).
