============================================================ | | | M E S O N ... considered ... | | xxx | | x x ,-_/,. ,_ . | | x x ' |_|/ ,-. ,-. ,-,-. |_ . . | | | x x /| | ,-| | | | | | | | | | | x ####### x `' `' `-^ ' ' ' ' | `-' `' | | x # # x ' | | x # # x | | x # # x | | x # x | | xxxxxxxxxxxxxxxxxxx | | | .__________________________________________________________. | | | Many Free software and/or Open Source projects this day | | and age are switching away from old tried and true tools | | such as GNU auto tools to meson. | | | | This phenomenon isn't particularly new, if you've been | | around for a while, you'll remember this happened before | | with jam and then, notably, with cmake. | | | | Meson being the latest fad in build systems however, is | | particularly annoying if you're fond of more esoteric | | platforms, old or new, because it depends on python, and | | it's ecosystem, and a rather new-ish version at that. | | | | I always found the python ecosystem to be particularly | | fragile, as they don't care much about keeping backwards | | compatibility between versions. And now that projects | | don't even care to make things work with OS package | | managers anymore, and instead, their build instructions | | mention 'just' grab <long list of dependencies> from pip | | / pypi, getting reliably reproducible builds for these | | things is harder than ever. As such, I'm finding this | | latest meson fad particularly problematic. | | | | Meson promises to make things "easier" on developers, by | | being on the surface, 'simple', but everyone who's done | | this for a while knows that 'simple' usually means worse | | in practice, and I believe this holds true for Meson. | | | | Even during the previous autotools exoduses, I always | | felt a bit like we were collectively making a mistake, | | because the proposed alternatives were missing something | | important. | | | | Autotools helps you in writing cross-platform software | | by scanning your source files for platform-specific | | things, and letting you know you probably ought to add | | a configure check for those. It can then also output a | | config.h file with definitions for things which are and | | are not present on the current platform, such that you | | may provide alternative implementations within your | | source code. | | | | If I run `autoscan`, for example, in the fvwm3 project | | root, it comes up with the following: | | | | configure.ac: warning: missing | | AC_CHECK_FUNCS([gethostname]) wanted | | by: fvwm/fvwm3.c:2171 | | | | What it's complaining about here, is that in fvwm3.c the | | gethostname() function is used, which is a platform- | | specific function that may not be present on all systems.| | | | It has similar warnings for many other functions used | | throughout the project. | | | | Not all checks are about functions, they can be about | | architecture specific things, like endianness, etc,... | | | | So, you can see, the autotools strategy towards helping | | you write portable software is not hardcoded platform | | names like you see in many projects, like the old | | ubiquious #ifdef __WIN32 or #ifdef __FreeBSD__ etc, but | | rather, granular checks for individual features and | | platform characteristics. | | | | The benefit of this approach is that not only does it | | give your software a fighting chance to run on more | | platforms, it also gives more descriptive errors for | | other developers looking to port your software to their | | platform. | | | | These days, most developers don't care if their software | | runs on more than just GNU+Linux/Windows/Mac, and maybe | | the BSD's if you're lucky. And it seems, people have | | written off autotools as some archaic boomer tool. | | | | While M4 might not be the prettiest language to write | | your platform checks in, I think the approach used by | | autotools is the correct one, and I haven't seen a build | | system with an equivalent system. This isn't just about | | supporting ancient legacy platforms, but also new ones. | | If I were to write a new OS tomorrow, these platform | | checks would be just as valid for my new OS as they are | | for the ancient platforms. It's just the sane, correct | | approach to writing portable software. | | | | Yes, you can manually write these checks in cmake or in | | meson, as these build systems do have ways to check if a | | particular function is present, or if a particular | | header is present, but none of them have these checks | | built-in, in the way autotools has them, and none come | | with a tool equivalent to `autoscan`, which means that | | you won't even KNOW which checks you're missing in your | | software. | | | | I can tell you autoscan has warned me about stuff I | | hadn't even CONSIDERED to be a potential porting issue. | | It is extremely helpful. There is so much historical | | knowledge contained within these tools, I sincerely | | believe that we as developers ought to think twice | | before throwing out the baby with the bath water. | | | | If you're writing proprietary software, where you're | | targetting only very specific supported platforms, none | | of this really matters, and of course, meson or cmake | | seem more than fine. And I think what we've been seeing | | over the past decade or so is an influx of developers | | who came from that world primarily, and get weirded out | | by the tooling in the Free software community, and bring | | their pushy politics with them, for whatever they do not | | understand surely must be bad and ought to be shunned. | | | | Of course, everything gravitating towards monoculture | | doesn't help. Many developers aren't even aware that | | other platforms even exist. And while this problem has | | been a thing for a while now, I find that meson | | depending on python just made the problem so much worse | | once again. | | | | But I also found that many people aren't aware of these | | issues or understand how autotools is intended to work, | | so I hope this helped someone out there understand! :) | | | `---------------------------------------------------------'