rust-opendingux-test VS meson

> By cross-compiling one usually understands compiling for the same OS but different architecture.

I don't even consider that to rise to the level of "cross compiling".

Getting started with emscripten to target WASM for C and C++ is rather a chore of dependency wrangling IME. Targeting WASM from Rust, OTOH, is trivial. Targeting windows from linux with Rust is also quite straightforward, as has been experimenting with targeting consoles or Android from Windows.

Targeting a MIPS32 OpenDingux target from Windows was much more of a chore. The toolchain with libs, headers, etc. that I used is just a *.tar.bz2 that expects to be extracted to /opt/gcw0-toolchain of a linux distro specifically, and embedded absolute paths all over the place make changing that difficult. I do resort to WSL on Windows, basically only because of those embedded paths: https://github.com/MaulingMonkey/rust-opendingux-test

Acquiring the appropriate libs and headers to link/compile against for cross compiling is always an adventure, but Rust isn't making things any worse IME.

With cargo-c I try to use the best practices to support as many platform as possible, trying to stay in sync with what meson does. Sadly what is conceptually trivial, installing a package, has lots of details that are platform-specific.

[1]: https://github.com/mesonbuild/meson/issues/8153

As it happens, I recently landed a PR in meson to add a clang-like Weverything mode that includes all of that, so you can get a minimal list of more or less all GCC warnings, organized by version, from the meson source here: https://github.com/mesonbuild/meson/blob/710a753c78077220b13a9f7e999dcdb61339efb1/mesonbuild/compilers/mixins/gnu.py

Came here to post the same. The answer for How to build software? is Meson[1] for C and C++ and also other languages. Works well on Windows and Mac, too.

I’ve written a small Makefile to learn the basic and backgrounds. Make is fine. But the next high-level would have been Autotools, which is an intimidating and weird set of tools. Most new stuff written in C/C++ use now Meson and it feels sane.

[1] https://mesonbuild.com

If you are very fortunate, you'll be able to choose something else. I like meson myself: it looks a bit like python, it's popular, small, simple, well-documented, easy to install and update, and it works well everywhere.

I suggest changing the build tool. Meson improved C and C++ a lot:

https://mesonbuild.com/

The dependency declaration and auto-detection is nice. But the hidden extra is WrapDB, built-in package management (if wanted):

    https://mesonbuild.com/Wrap-dependency-system-manual.html

> C's only REAL problem (in my opinion) which is the lack of dependency management. Most everything else can be done with a makefile and a half decent editor.

Care to hear about our lord and saviour Meson?

Both of your quoted problems are mutually incompatible: dependency management isn't the job of the compiler, it's a job for the build or host system. If you want to keep writing makefiles, be prepared to write your own `wget` and `git` invocations to download subprojects.

Meanwhile, Meson solves the dependency management problem in a way that makes both developers and system integrators/distributions happy. It forces you to make a project that doesn't have broken inter-file or header dependency chains and cleans up all the clutter and cruft of a makefile written for any non-trivial project, while making it trivial to integrate other meson projects into your build, let other people integrate your project into theirs, and provides all of the toggles and environment variables distribution developers need to package your library properly. You can really have your cake and eat it too.

https://mesonbuild.com/

Other people going down this route seem to end up writing cmake replacements instead. I'm thinking of something like meson here except that meson never intended to transpile to cmake.