{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihzh6ap6hntyhqyfd3atrj6hyiwoafturj46a7zm34w4hneumtp7q",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mj35tptp57w2"
  },
  "path": "/viewtopic.php?t=33306&p=272088#p272088",
  "publishedAt": "2026-04-09T13:10:19.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> I've considered doing this as I know how to, but the thing is: I only know how to build these things in tools that are Windows-native.\n\nSomeone else could take over the task of building a GUI using a language and tools that allow cross-compiling or are available on both Windows and Linux (and Mac). Such as FreePascal and Lazarus, for example, which is what both CudaText and DoubleCmd - two of my tools of choice - are built with. Or Python and wxWidgets/Qt/Gtk. Or C/C++ and Gtk (like Claws-Mail; _what ever happened to them? home page is unreachable_). Or whatever.\n\nAnd maybe all a GUI would do would be to build from scratch - or correct, if existing - the .mozconfig file. That way people that prefer CLI could build or edit that file themselves directly, while others who are unsure of the process or the options would use the GUI. In time the GUI might even gain popularity if:\n- it has a user-friendly layout\n- provides best defaults\n- it's intuitive\n\n> So who would I be building it for then?\n\nFor everybody.\n\n> Then what they are doing is already a bad start\n\nGranted, but they are probably beginners, and in time they'll learn - if they will be helped to.\n\n> multiple invalid/deprecated options would take just as many 15 second starts of the build process to be told which ones are the problem, right on the screen when the failure happens.\n\nCurrently the Python2 script breaks with an uncaught error on **first** invalid option it encounters. If it went through **all** options and in the end listed **all** of the invalid ones in a single batch, and then [gracefully] interrupted the build process, then it would have been a one-stop operation; a good lesson for beginners but still annoying in situations like the current where a deprecated/removed option that doesn't affect the build process in any way still stops the process.\n\n> 8GB is fine if you don't go overboard on parallel compilation tasks.\n\nAs mentioned somewhere in a post above I set the build to two concurrent threads (-j2) which doesn't take memory consumption over 7GB in normal circumstances. But if I were to open other applications - such as a file manager, a text editor - and perform certain operations, would it then be safe to restart the build process after an interruption? Would anyone guarantee that the subsequent build would not be affected by those operations, that it would still have enough memory to not go into swap or do something... abnormal?\n\n> we can't start doing a whole multi-cycle deprecation development flow for each configure option we touch.\n\nThis is the part where I don't quite understand what you mean. I didn't ask for pre-notifications or anything for N releases ahead before deprecating some option - just that, once an option was deprecated/removed it would be clearly indicated as such in the build log, allowing the user to remove it from the configuration file only **after** the build is finished, if no other error creeped in. A simple file holding the names of all [recently] removed options (maybe followed by release version where it happened) would've been enough for the Python script to parse.\n\nAs I understand it, a deprecated/removed option should have no effect whatsoever in the build process. Maybe I'm wrong abut that? But as long as it doesn't affect the build in any way, why stop the build process?\n\n> Not doing such a check would have people assume things work and then complain or be confused and want answers if they did not.\n\nI never asked for a no-check, I wouldn't agree to that myself. But at most, comment out that bad option automatically through some script sometime during the build process, together with adding another comment specifying the reason (i.e. # enable-jxl/disable-jxl were deprecated and removed in v34.2.0; do not use). If the user ever checks the config file at a later time they'll acknowledge the change and the reason; if not then next builds will have no reason to complain about that particular option ever again. Would that be feasible and acceptable?\n\n> It just isn't the case here that you would have or can assume zero-maintenance as we continue to develop.\n\nWhy not strive to reach as close as possible to that...?\n\nOK, _much ado about nothing_. Let's leave this topic to bake, see how it goes with the switch to Python3 and other more pressing issues. Maybe more/better ideas will come up in the mean time.\n\n* * *",
  "title": "Browser Development • Re: 34.2.0 build failed, --enable-jxl unknown ??",
  "updatedAt": "2026-04-09T13:10:19.000Z"
}