- Feedback on the Meson project ...
I have had a little exposure to Meson when building Picolibc. Meson does not take cross-compiling seriously, there have been several bug reports about it over the years. For example: https://github.com/mesonbuild/meson/issues/4694 I had to write a script to be able to pass build flags on the command line, like everybody else: https://github.com/rdiez/DebugDue/blob/master/Toolchain/Tools/GeneratePicolibcCrossFile.sh Picolibc is using an older version of my script: https://github.com/picolibc/picolibc/blob/main/scripts/GeneratePicolibcCrossFile.sh Comments like this caught my attention over the years: https://github.com/picolibc/picolibc/issues/92 "If I correct understand, multilib is way to build picolibc binaries for many architectures by one meson build call. This behavior is against very idea of a Meson." More example bugs I have been collecting in this area: Cross compilation and complex build setups https://github.com/mesonbuild/meson/issues/5363 RFC: Heterogeneous architecture projects for meson https://github.com/mesonbuild/meson/issues/8557 machine files, replacing the cross file https://github.com/mesonbuild/meson/issues/3972 But OpenOCD is no firmware project with heavy cross-compilation needs, to it may not be affected but those. The Meson project still has over 1900 bugs open: https://github.com/mesonbuild/meson/issues/ The trouble is, the Autotools are indefensible, and CMake has a lot of criticism too. I have collected some of it over the years: - The language is a full blown programming language with no debugger and very bad syntax (space inside variable names, any undefined variables just evaluate to empty string...) - Unintuitive behavior everywhere (SET will not actually do anything if the variable was present in the cache) - There are many complaints about CMake's documentation. - CMake's syntax is ugly as hell and everything is too complicated than it should be. - Also it [Meson] repeats CMake's mistake of rolling its own scripting language, which is pretty much always a bad decision because: 1. They're not professional language designers. That language won't be as good as properly designed ones. 2. It's a lot of work that isn't needed, pointlessly increasing the project's cost. 3. It doesn't have any ecosystem, while existing general purpose scripting languages do, including libraries, tutorials, and people who already know them. 4. It's a waste of the user's time to learn a language which is only used for a single tool, and is completely useless elsewhere. - As much as I hate autoconf, it does one thing right: to generate an installation script (i.e. configure) such as end users do not need to install the build system first. Regards, rdiez
