{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreid3gzk4d5e7jmxel7tvmah3d245gfx4gm5ezini237h5uhp2b54s4",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3miz2lepwzxb2"
  },
  "path": "/viewtopic.php?t=33306&p=272053#p272053",
  "publishedAt": "2026-04-08T17:53:26.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> I feel the issue hasn't been understood correctly and completely. It's not about a slight nuisance, or resource constrain or anything - it's about not wasting user's time, it's about not breaking the work flow.\n>\n> I didn't do all that mumbo-jumbo with clearing memory just because resources are scarce; I could well run a few applications along with building PM, including a text editor. But it's been mentioned so many times by Moonchild that certain crashes could be the result of buiding PM in a fragmented memory environment, like switching to swap etc. And since I'm self-building I don't have the right to complain about various issues, so I've been trying to minimize any and all possible risks - hence starting the build process in a clean, hopefully contiguous memory. I don't think any of us knows precisely how their OS works in this regard, how memory is used by various applications and the OS itself, so we can only do what we think it's right.\n>\n> To that end, stopping an otherwise sound build process only because a configuration option is no longer valid - without it having any kind of impact on the build process itself - only wastes user's time, having to reiterate the memory safety procedure regardless of whether editing that darn config file is done in console/terminal or in a fancy text editor or whatever.\n\nUhh... not to be dismissive or anything, but when programmers start talking about contiguous blocks of memory or fragmentation, that's often a tell that they aren't really sure what the problem is or can't reproduce it themselves. If versions of tools and libraries are verified, and we see nothing is weird, then of course everything shifts to less verifiable concerns like the memory layout or a subtly broken environment that appears fine. I wasn't there when MC said those things, so I don't know for sure... but from what I know of programmers and MC in general, I suspect you might be taking his words in this situation more seriously than he ever intended. I'll go out on a limb and say I really think, personally, that 8GB should be enough to build the browser safely, I just assumed from what you were doing you must be trying to build with 4GB or less. That said, I know you take this seriously, and if you're worried... there's always this option:\n\n\nCODE:\n\n\n    mk_add_options MOZ_MAKE_FLAGS=\"-j1\"\n\nWhich will take forever but makes the build more deterministic and reduces the chances of any kind of corruption introduced by memory layout or anything like that because it runs just one make process at a time.\n\nThe other thing is, from what I've gathered... BleachBit only clears up fragmentation in disk space, not RAM. And the concerns MC had were likely about contiguous blocks of RAM, not contiguous blocks of hard drive space. AFAIK, there aren't really any utilities that can help with RAM fragmentation. What you'd have to do to even try and mitigate that concern is basically reboot the machine and build in an environment where you haven't been running a lot of stuff before starting the build, maybe even boot into terminal mode so X11/KDE/GNOME don't start messing with your RAM too and playing around too much. Which, if anything, wouldn't make your overall concern less valid if you're having to boot-cycle the machine between build attempts due to fear of RAM fragmentation.\n\n\n> Configuration options can vary so much from user to user (or better said, from environment to environment) that a default .mozconfig would be almost useless.\n\nYeah, that's the main reason why we haven't done this... it would solve minor inconveniences for the average builder, but then the average user is likely able to use official builds anyway, and it still wouldn't help much in edge cases like yours.\n\n> But since any change to the build options would have to be noted somewhere somehow, why not just do as I suggested the first time: whenever an option is deprecated, type its name in a text file, have that text parsed by Python when validating the config, and notify the user about the deprecations **without stopping the build**. Those who can afford the risk could edit their config file right away upon seeing the notifications, others (like me) would do it only after the build completes - or breaks for whatever other reason - and whoever doesn't care to read the build log and heed the notifications can go to hell, period.\n\nCorrect me if I'm wrong, but doesn't the build usually stop very early with an \"error processing mozconfig\" or something if you use an invalid option? I'm pretty sure it's not supposed to get that far in. Granted, it will just say \"invalid build option,\" but it isn't going to waste your time by pretending it will build and then getting halfway through. It actually shouldn't be getting to code compilation _at all_ in that situation, and if it is that may be a bug/regression. I thought you were just complaining that the error message was too vague.\n\nThe thing that's worth noting is that your concerns are actually inverted from those of the average developer. Usually letting a build continue when the system is unsure is the thing that's seen as risky, stopping it if you're not sure what the user meant to specify is viewed as \"safer\" if anything, even though it's annoying.\n\n\n> I assume the Python script(s) can remove the invalid options before passing on to a new stage. Or if not, something like that could be implemented. I have not yet gotten to analyze the PM Python environment - neither the old nor the new one.\n\nWell, there is one issue with that... essentially, mach has to bootstrap itself in order to read in a .mozconfig file, and the process that ultimately turns the mozconfig into parsable tokens is implemented as a very dumb shell script, not as actual Python code. So there's actually very little we could do given those constraints. Other than just silently ignore _all_ invalid .mozconfig options and treat them as if they were not specified, which would likely annoy other developers in different circumstances.\n\nAll of this said, there is one \"cheat code\" I think I can present you with that will give you what you need, as long as you know where to look. In your terminal, before typing ./mach build, do this:\n\n\nCODE:\n\n\n    cd platformgit log -- build/moz.configure/old.configure\n\nIf you do that, you will see, fairly close to the top:\n\n\n> commit 7fca2b8de39e9aaeaa594f814c45c7ae03267ff1\n> Author: Moonchild <redacted e-mail address>\n> Date: Sat Mar 21 11:57:15 2026 +0100\n>\n>  Issue #2739 - Follow-up: remove missed configure bits.\n>\n>  We still accepted {en|dis}able-jxl as a valid old-configure option and\n>  there were a few leftover pref conditionals.\n\nThat is to say... every single time we remove or add a configure option, we pretty much have to touch that file due to the way the build system works. So doing a git log on that file is a great way to see what build options were added or removed recently, though there may also be some noise if the file was edited for other reasons.\n\n* * *",
  "title": "Browser Development • Re: 34.2.0 build failed, --enable-jxl unknown ??",
  "updatedAt": "2026-04-08T17:53:26.000Z"
}