added script to generate .cargo/config from toolchain environment 💪

[ju6ge]

This commit adds a python script to generate the correct .cargo/config for the installed toolchain. All path are extracted from the environment variables after sourcing the toolchain's environment file.

[bkirwi]

A few suggestions, but overall great!

[ju6ge]

I incorporated your suggestions.

[LinusCDE]

The script seems fine so far. Just added a few little things below this comment.

I also tested out whether all toolchains work, and it only worked for oecore for me:

I used the source commands I added to the file for each respective toolchain. They all run into your exact issue #101 and attempted to build the example in dev mode after running the script gen_cargo_config.py.

The .cargo/config for poky was the exact same, I had used earlier in my projects. So I would suspect that this is due to some legacy issue??

For the codex toolchains I now confused myself as well. I ensured that the paths all exist (installed to standard locations), so it's probably not a typo.

Any suggestions on this?

Edit: A few more informations on my test-setup:

• Command used to build: cargo build --target=armv7-unknown-linux-gnueabihf --example demo (respective env file was sourced before)
• Using a recent Manjaro Linux. All 4 toolchains are installed to their standard locations.

[ju6ge]

Hm so I tested the script for the oecore (latest) and codex (3.1.15) version installed on my system. Both work fine in release as well as in dev mode. 🤔 Has anyone else tried using the script yet?

I can test this in more detail on the weekend. Currently I need to focus on getting my master thesis submitted this week 🙈 😆

[LinusCDE]

I can test this in more detail on the weekend. Currently I need to focus on getting my master thesis submitted this week

Nice! Don't put yourself up with this then. We're not in a hurry!

[ju6ge]

Okay so I submitted my thesis and now I have some time for a closer look. I took my laptop as a clean environment where I have not built libremarkable previously. I have installed all 4 toolchains: poky, oecore, codex: rm10x and rm11x. For every toolchain I am sourcing the environment file and running the generation script, afterwards I build the demo binary in dev mode:

Codex rm11x: Builds ✅

Codex rm10x: Builds ✅

Oecore: Builds ✅

Poky: Builds ✅

I could not find a problem with any of the toolchains in a clean environment. So I am a bit confused why they don't seem to work in your setup. Any ideas?

[LinusCDE]

I could not find a problem with any of the toolchains in a clean environment. So I am a bit confused why they don't seem to work in your setup. Any ideas?

Not sure myself tbh. I checked against typos at least and poky definitely used to work as I used it for a really long time. Maybe it's some rust toolchain changes and or lib incompatibilities in my system.

Since you've shown that all toolchains work, I don't have anything against merging this now. Using this, is a far better system than before. I'll probably do the same in my repos, and drop a quick explanation + link to this python script in the readme of those projects. I'm up to merging this as-is.

Anything to add/change in your opinion @bkirwi ? Otherwise I'll just merge this in 2-3 days or so.

[fenollp]

Off topic: what kind of advantage does one get by using one of the possible toolchains instead of a somewhat generic one with cross?

If it's about linking with the right libs/versions, does musl present more disadvantages than pros in your experience?

Thanks for your work

[LinusCDE]

Not sure if this was a general question or one at @ju6ge .

Imo, I don't see a real benefit for most rust applications as well.

If I had to guess it would be stuff like:

• Performance benefits and possibly more optimizations with a more recent gcc (e.g. for system libs like zstd-sys)
• If some rust dependency would link against a shared library, "generic" toolchains only have the bare minimum or possibly wrong version that are not present on the system

The second point usually only seems to highly matter for qt libs. You could use it in rust, but I have not seen anyone using it yet. And openssl is also only shipped as a binary which necessitates vendoring the lib anyway.

GCC version of all the toolchains:

Please correct me if anything as missed or misrepresented. (I usually prefer an older toolchain as this prevents glibc version errors which I had plenty for work related stuff lately. That forces a binary only to run on very recent distro versions.)

[bkirwi]

No objections here! Since we're keeping the example in the README this should have no downsides.

Off topic: what kind of advantage does one get by using one of the possible toolchains instead of a somewhat generic one with cross?

Personal example: some of my code depends on the tflite crate, and cross' built-in toolchains can't build that out of the box. I think any env vars etc. you may need to set are a bit more awkward with cross as well. I suspect these are solvable problems... but so far I've had an easier time using reMarkable's toolchain, and installing the other stuff I needed manually, than building a custom docker container with everything I've needed.

[ju6ge]

I really only used cross once, so not sure … I think the benefit lies more in the fact that you can use it in situations where you do not have access to an official toolchain. Apart from maybe a streamlined installation path and build environment. 🤷‍