{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreieknfdkhh7e2yjtc4laih6wesqa5zzgkva3fgmouoiovg2bnnlnri",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mkdjubxyccu2"
  },
  "path": "/viewtopic.php?t=33374&p=272770#p272770",
  "publishedAt": "2026-04-25T16:45:10.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "My opinion after working with the build system a lot is basically this. Autoconf and make themselves are fine, they are fairly old programs that don't change behavior much, known quantities. However, there is one wrinkle to working with them that I am not a fan of, and that's when we start having to deal with cross-platform shell issues. Essentially, a lot of our shell scripts are written as \"best effort\" POSIX-style sh, which often means it only works with bash, or only bash and dash, or works in say, bash and ksh but not in dash (that actually happened once). Then there's also ash on NetBSD and similar. The problem is, shell scripts tend to rely on /bin/sh, which could be just about anything. In some ways, dealing with all these cross-platform shell issues is actually worse than Python or Perl because of the inconsistent behavior.\n\nSo my feeling is really that I would prefer to stick to Perl for anything that would otherwise be a complicated shell script with a lot of potentially platform-specific quirks. It works well with GNU Make and Autoconf as a sort of alternative to a shell invokation, but it isn't as \"heavy\" as Python and sits comfortably between being what Python is, and being an advanced way of writing a shell script. I guess that means my ideal preference in the end would be... Python mostly for mach and mozbuild, Perl for anything beyond the most basic shell scripts, and make/autoconf for configure. I know autoconf and make seem like unfriendly programs to newcomers, but I think after you work with moz.configure a bit and see how restrictive the sandbox is, you'll come to appreciate that the alternative is not better, and may even be more painful and complicated because of how it forces you to deal with anything beyond pointing at a directory and telling it where some sources are as if you are doing it for the whole build system rather than just the task at hand, and it also forces you to deal with the rules of yet another sandbox while doing that.\n\nThe one thing I can tell you for sure after going through the tree is that there are a lot of things done in Python in our tree that really, really should _not_ be done in Python. We're talking codegen, writing stuff that's basically stopping just short of being a compiler, etc. In Mozilla's defense, early Python 2.x era was a much lighter program that wasn't changing rapidly. But in Python 3, a lot of this heavy lifting being done in Python rather than Perl or C is hurting us a bit on build times because Python instances are more expensive and it loads slower. Not only that, but the code is hard to maintain because Python isn't really designed for writing compilers or codegen and that stuff bitrots fast... stuff that probably should have been done in C, or using a helper like bison or flex, etc. Just... not Python.\n\n* * *",
  "title": "Platform Development • Re: Autoconf dependency removal?",
  "updatedAt": "2026-04-25T16:45:10.000Z"
}