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.
Our workaround for getting meson and cargo working together
included a separate 'release' target that replaced
'ninja dist' so that we could vendor dependencies.
Now we use meson's add_dist_script to vendor the
dependencies as part of 'ninja dist', so we no longer need
the 'release' target.
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.
This adds a configuration option in meson, if set it changes the
application ID allowing for stable and development version to be
run at the same time.
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.
Added translation support based on the Fractal i18n. To do this I've
added the gettext-rs crate dep. I'm using my own fork because the
official gettext-rs release includes the gettext source files and that
increase the distribution package a lot and for distribution with
flatkap we don't need to build gettext, the lib is in the gnome sdk. So
this gettext-rs fork is the same, but removing the not needed gettext
source files.
The i18n.rs file adds some useful functions to translate strings. These
functions wraps the original gettext and adds more functionality, to be
able to translate compound strings, something that's not supported by
the gettext function.
The 'i18n' function works like the gettext, receives a plain string
without params.
The 'i18n_f' function receives a string with "{}" and a ref to an array
of &str with substitutions for the "{}" in the original string. The
substitution is done by order.
The 'i18n_k' function receives a string with "{named}" and a ref to an
array of (&str, &str) with substitutions for the "{named}" in the
original string. The substitution is done by name, where the first &str
in the tuple is the name and the second the string to use for the
replace.
This mod also include ni18n variants of the three functions for plural
and singular translations.
I've also created the spanish translation.
See #61https://gitlab.gnome.org/World/podcasts/issues/61
