strop VS cargo-msrv

I am completely rewriting strop, (the code sucks, and I know Rust a lot better than when I started, so I wanted to make it a bit better structured and more idiomatic). And I like to have static analysis make sure my code has certain qualities, so I stick this:

Do you think it's an architecture for strop then? It has a focus on code-generation on platforms not well supported by mainstream compilers

Here is a project for generating code for CPUs that do not have much support from mainstream compilers. Currently supported are the 6502 and the STM8 (I'll possibly be adding others in the future, feature requests welcome).

I could use some help on my project strop. Feel free to take a look and see if it's the kind of thing you feel you could contribute to! but be aware that the quality of the codebase is poor. There's a pull request to address this though.

It is my first time of making a Rust library. Actually, my project strop has been a binary crate and only recently have I started trying to use it from a different crate. This is happening on the breakapart branch.

Still working on a big rewrite of strop.

If you're offering free help, then I could use some help with my project strop. (TL;DR: instead of compiling code, it's evolving code. And it has a focus on architectures that don't have good support from mainstream compilers, but I'm open to adding other architectures as well).

My frustration with this kind of situation (and PICs are not unique here, the 6502, CP1600 and other very low end chips have similarly problematic toolchaining) led me to invent strop, for evolving code sequences. It has some basic PIC support.

Hadn't thought of this. I even encountered it recently too.

I am still working on strop. (TL;DR alternative to compiled code, it's evolved code. Tell it which function you want and which registers to use, and it'll randomly generate an assembly language program that does what you wanted)

What this tool say? https://github.com/foresterre/cargo-msrv

I'm working on cargo-marv.

Before getting overcome by despair, have a look at cargo-msrv -- this little gem of a tool figures it all out for you!

I'll be adding a 'minimal' output format to cargo-msrv for use in scripts. I'll also be updating the book, and inch closer towards releasing v0.16.

First commit 2 months ago, started with edition 2021. https://hg.sr.ht/~cyplo/legdur/browse/Cargo.toml?rev=ca11815...

Have you tried compiling something less than bleeding edge, with a year old compiler, or are you picking projects specifically to "showcase" the supposed failings of the Rust compiler?

Many libraries in the ecosystem have a MSRV (minimum support rust version) guarantee, with compile-time shims to enable newer features if a more recent version is detected.

You can pin your dependencies to those versions (and if they don't have an explicit MSRV, just pin it to a version by date or by running https://github.com/foresterre/cargo-msrv on the project to find the effective MSRV).

You can cargo install specific versions of a binary crate, and if they move to the 2021 edition, or use a recently stabilized standard library function or w/e, you can simply choose to install a specific version, that would work with your distro's rustc/cargo.

I'm not even talking about the completely valid, but last resort strategy of many non-bleeding edge distro package maintainers, of simply creating a .patch file and applying it. In legdur's case, --- edition = "2021" +++ edition = "2018" on Cargo.toml would probably do the trick. For libraries/binaries you control, you can use https://doc.rust-lang.org/cargo/reference/overriding-depende... and https://github.com/itmettkeDE/cargo-patch.

Giving up after the first minor roadblock and crying bloody murder is intellectually lazy.

Looks helpful though it doesn't seem to address when you don't have a Cargo.lock. I've created an issue for this.

I'll be switching over the CLI of cargo-msrv, from Clap's builder methods to the attribute macro. I hope this will simplify the configuration, as my Config and ConfigBuilder structs (which were build from Clap's ArgMatches) was growing fast, and becoming slightly unorganized. With the attribute macro, the config will be constructed directly by code generated by the macro. The mostly saves one intermediate step, and a lot of boilerplate.

Some combination of cargo-outdated and cargo-msrv could probably do this in a slightly more manual fashion.