It appears that cross-compiling with Rust is rather straightforward: just install the target you're… hmm, targeting with "rutsup target add <target>", and use "cargo build --target <target> --release" — not much harder than it is with Go.
Considering that your target is available via rustup — mine, PowerPC MUSL system wasn't and I had to build natively, I'll figure out how to add my own targets later. But building for my old ARM machine went without a hitch — and, surprisingly, the binary works😂
Some problems arise from software relying on atomics (thread-safe types) from the standard library, which aren't portable — luckily, there is portable-atomic crate: https://github.com/taiki-e/portable-atomic
Replacing atomics from standard library with the ones from portable-atomic IS straightforward, but in my case it was a dependency of a dependency using it, so building the RSS reader involved adding a [patch.crates-io] section to Cargo.toml to use a local patched version of crate.
Now I have to figure out how to make ureq in this RSS reader use the proxy set with environmental variables. It looks trivial to accomplish: a matter of implementing the Default trait, which is now derived, for the structure (which would be an object in classic object oriented language) that is used as HTTP client.
In Go this wouldn't have been a problem as HTTP client in the standard library honors the environment variables for proxies, but in Rust standard library is very limited — there are plenty of widely used and good crates to make up for it. ureq, which is used in this project, doesn't do it, to me it looks a very similar to Python's great requests module, in which you have to construct the session object (Agent in ureq) and to configure it to use proxies and which is then used to execute requests.
Wow, turns out I didn't have to do any of this myself and there is a way to make ureq work exactly the same way Go standard facilities for HTTP requests do: this crate has "proxy_from_env" feature 👍
@romin
For me it's more about experimenting with Rust and seeing how well it works on marginal architectures (so far so good) than about making the RSS reader work. It's not even that good TBH — very basic, I don't think I'll keep using it even 😂
For me installing that web-based behemoth in Python would make more sense, can't recall its name — it has accounts and uses PostgreSQL DB for its data. I really like TUI, but I want images in my feeds to easily tell the articles apart 🤷
@romin
This is the thing I meant: https://github.com/NicolasLM/feedsubs
It looks nice, but it has so many moving parts (Django, Postgres, Redis 🤪) and as I'm not using Dorker, I'm not ready to invest time into hosting it myself yet. I'm using like 4 different machines and a couple of phones more or less daily so having a centralised reader for RSS and not updating the feeds on every machine individually looks like a good idea.
>Host installations are not supported starting 2021. Consider using Docker when planning new tt-rss installations.
In case some of the crates use C code and build something themselves, like ring crate does, you have to point cargo to the right tools using the environment variables, but in a lot of cases it figures everything out on its own.
Also rust crate version 0.16 didn't support 32-bit PowerPC properly so to port TUI RSS reader here https://github.com/veeso/tuifeed I had to update a few dependencies to use newer ring 0.17