{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigtzfpwubfxr6u4yowndyj5fvw27blirit2mjgcbk3nzhga3bw7sy",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mizoqz6gcjr2"
  },
  "path": "/viewtopic.php?t=33306&p=272068#p272068",
  "publishedAt": "2026-04-09T00:18:47.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> ]Yep, that's the main point. And as I mentioned in one of the previous posts, it would be even more annoying and time-consuming if there were more than one deprecated options and the build would stop over and over again N times until all of them are exhausted. A wise person would avoid rebooting after each config edit, but one never knows. That's one more reason to have them singled out in the log all at once so they could be wiped out in one sweep.\n\nAh, I see. It is worth noting that we usually don't deprecate more than one build option at a time, precisely because we know how annoying this would be to deal with too often. For example... when I am bisecting builds and trying to trace down an error. Sometimes I have to add deprecated options back to my .mozconfig and comment out newer ones as I'm going, then reverse the process as I walk back up to see where an issue came up. It's to the point where I just comment out the old options with an # symbol in case I have to roll back to an old build and specify it again during some convoluted test. I just usually don't think about it because am in and out of the editor so fast... but yeah, if I were doing your workflow and I didn't have vim muscle memory, it would upset me more, I admit it.\n\n> And by the way, my desktop is Cinnamon 4.2 (in Linux Mint 19.2).\n\nGood to know, I actually have a VM of that environment laying around already, so I can test it.\n\n\n> That's no wonder, I've always done things somehow differently than most people. How many people do you know that **never ever** use the Recycle Bin/ Trash Bin? I've set all my systems, in time, starting with Win95 to delete everything directly bypassing the Bin. However, when launching Updater I closely look in the changelog tab of every file before selecting it, and if anything doesn't look right it won't get it. Most people don't even care what has actually changed, and in [current] Windows I'm not even sure it's possible. I never ever used a firewall or a resident antivirus in Windows and never got infected (despite visiting sites like Astalavista - for who remembers it), yet friends of mine using both were coming to me to fix their infected systems.\n> So yeah, I might do things differently but it doesn't necessarily mean it's wrong. If I let things go despite some notification/warning I know what I'm doing, and I'd much like for those things to go smoothly.\n\nI can relate on this one, I also never use the Recycle Bin and wind up emptying it immediately or disabling it. I don't delete something unless I actually want it gone... the cache is an annoying layer. Didn't mean to suggest the way you do things is inherently wrong, so much as it's imposing a tax on you that no one else building the browser is paying.\n\n\n> Did that and the entry you mentioned looks... ambiguous. Could easily be overlooked or mistaken for something else. It's not like it says cleary: removed enable-jxl and disable-jxl options from .mozconfig. That would've been crystal clear for everyone. And, well, how many of those that build for themselves know to look there and actually understand what it's all about? You must admit those are very obscure operations. I'll probably forget about that command before tomorrow. _(mentioned failing memory earlier, my mother died with advanced dementia, I probably inherited it)_\n>\n>  Anyway, I get it: it's complicated, may or may not be possible to improve at some point in time. I/we will have to live with it as is until further notice.\n> Thank you all for your input.\n\nLike, I do think that it might make sense to put stuff like that in the release notes for self-builders, but I also think most people wouldn't read that anyway.\n\nBut yeah... listening to your issues and hearing that you have a primarily GUI-based workflow here is making me really think about this issue and how to streamline the build process. The truth is... I think the .mozconfig concept is a _terrible_ way to configure things to start with. Though in our defense, we did not invent it and I honestly think I would have done this differently. Manually specifying configuration options in a hand-edited text file is very old-school Unix stuff. I mean, even the Linux kernel was doing this better with menuconfig back in the early 2000s. I think if I were to try and fix this... I'd try to create some kind of graphical configuration utility that lets you see what options are available at a glance, what you've picked, and is able to reference a database to compare your saved options against what's available, maybe making note of options that have disappeared as it goes through your stored past selections. Editing a .mozconfig is fast for terminal people who can type fast like me, but it has to be a nightmare for anyone who is used to the GUI.\n\nI can really think of a lot of things that could be improved with a proper database and a GUI here. Like, we could flag if you haven't specified the minimum required options, we could flag stuff you did specify that that's no longer in our database of build options, etc. Fundamentally, the issue is that our build process is not GUI-friendly at all, and assumes anyone building a UXP application is comfortable with a text editor and familiar with the terminal.\n\n* * *",
  "title": "Browser Development • Re: 34.2.0 build failed, --enable-jxl unknown ??",
  "updatedAt": "2026-04-09T00:18:47.000Z"
}