Before we were able to call the script with ninja directly,
we were trying to override some of the envvars to fix how/where
cargo artifacts where stored.
This is no longer an issue as ninja is making sure the proper
setup will be met. This is also makes it so that Builder
doesn't rebuild everything since $BUILDDIR was empty before
causing rebuilds of the whole world.
Instead of putting target/ and target_test/ in the source
directory, we can tell our cargo script to put both target
and our cargo-home in meson's build directory.
In addition, makes tests and builds use the same target
directory, significantly reducing the time it takes to run tests.
Allows us to get rid of build.rs, which was only used to
compile resources. static_resource.rs is now created by
meson, and the meson path is used for include_bytes!.
Closes https://gitlab.gnome.org/World/podcasts/issues/55
This is not supported at all, and it still won't run with cargo
run, thankfully, you should use meson instead...
The only purpose of this commit is to make it possible for
cargo check, and by extension rls, to function and work
properly.
Part of #110
This requires a RUSTFLAG to be set before hand for rayon to build.
This brakes a lot of tools like rls and clippy by default and
require special configs for itnegration.
Additionally, rayon_futures is still 0.1 and not much work seem
to have gone into it. Ideally it should be replased with the tokio
runtime/threadpool.
I am not sure why, but cargo does not like it if flatpak-builder
and gnome Builder try to use the same target/ directory, even
though the environment should be almost identical.
The only difference is that Builder uses flatpak build instead of
flatpak-builder as far as I can see.
