{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiadbdjiizyhu53it4l6bhbsd3yeojwstoquhgxyczfesdvy43jhxq",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mkgi3edaedc2"
  },
  "path": "/viewtopic.php?t=33374&p=272810#p272810",
  "publishedAt": "2026-04-26T20:37:24.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> Sorry to be blunt, but isn't using a known tool available across oses more consistent than generic languages like perl or Python that can and will vary version to version and are often locked to distro specifics?\n> So, wouldn't that promote the use of autoconf or a known shell? I mean... Bash will act the same on linux, bsd and windows... But python might not, (see e.g breaking changes between python 3.10 and 3.14... And that is even just a minor version difference...\n>\n> Just hostly wondering if we're not making things harder, not easier, even regardless of the fact that I don't know Perl at all\n\nWell, honestly, there's no silver bullet, and that's one reason why I think there's a good argument in favor of leaving things as they are and dealing with issues as they come up, only considering migrating something off of whatever it's on if we have repeated issues in that area that would be solved by doing so (like with Python and people constantly not being able to compile Python 2 on Linux). In many cases, any change is potentially just trading one set of problems for another.\n\nLike, if I compare shell to Python... I see it as something like two different kinds of poison. Python is mostly an instance of what I like to call, \"version hell\"... it changes a lot from version to version, but is fairly consistent across platforms. If I write something in Python, then for the most part I know the same version of Python will work similarly across Windows, Linux, and other platforms. Especially inside venv or virtualenv, which is part of the reason why they set that up in the first place, to avoid any distro-specific packages polluting the vendored Python packages. So Python is actually much more consistent across platforms than shell, but less consistent across versions.\n\nIn contrast, shell is the reverse. Shells haven't changed much over time and have known quirks, but it's \"cross-platform hell,\" because all the POSIX-ish utilities it relies on work a bit differently from platform to platform. Even if you wanted to standardize on bash (we currently don't, and turning it into a build requirement would likely annoy all the platforms that _don't_ ship bash as /bin/sh), then the other utilities like grep, awk, etc... all have platform specific quirks. We would have to not only mandate use of Bash, but also GNU coreutils to make behavior consistent, which some distros like Ubuntu are moving away from even within Linux. And we'd likely have to use TOOLCHAIN_PREFIX in a lot more places and tell people to invoke the GNU versions of utilities explicitly, saying that we won't just support whatever POSIX-ish utilities your distro ships with, and won't support you unless you try GNU Coreutils and Bash first. I don't imagine that would go over well.\n\nAs a case in point... there a was a time when a certain person who used to work on this project kept wanting to replace pieces of Python with \"simple POSIX sh scripts,\" as he called them, and it seemed like every other time he would do it, it would cause weird problems on obscure Linux distros that don't default to Bash, one of the BSDs, or SunOS. I never dared say this when he was around, but I kind of hated those shell scripts for that reason, and honestly that's what soured me on the idea of doing everything as shell scripts instead of Python. Because as bad as Python is/was... it wasn't as annoying as dealing with a random mix of tools from random vendors that are all named the same thing and all vaguely POSIX compliant but different in just enough ways that you can't trust them 100%. It also doesn't help that most people who think they know something is POSIX compliant are totally wrong and only managed to test on maybe two or three popular shells that happened to support an extension they were using.\n\nThe only reason I mention Perl at all, is simply because I've found it to be a tool that is very conservative in behavior compared to Python, and also fairly consistent in behavior across platforms. I would also say that about GNU m4, which autoconf is written in. So the way I'm seeing it is... autoconf, perl, and GNU make are known, fairly conservative tools that are not changing fast. Python is reasonably consistent cross-platform, but changes really fast across versions. Shell is reasonably consistent across time, but varies a lot between platforms.\n\nSo yeah, I'm definitely not advocating for getting rid of autoconf or GNU make. I'm just saying... maybe I'm not eager to see more things that invoke a #!/bin/sh shebang in the tree and use a ton of utilities like grep, awk, or sed. I suppose it won't hurt anything to keep the battle-tested ones we have (I've never been a believer in change for the sake of change anyway), but I definitely think it's safe to say I don't think it's the right direction for new code.\n\n* * *",
  "title": "Platform Development • Re: Autoconf dependency removal?",
  "updatedAt": "2026-04-26T20:37:24.000Z"
}