34.2.0 build failed, --enable-jxl unknown ?? Topic is solved

[Drugwash]

Last time I built PM 34.1.0 with the very same .mozconfig and it went through just fine, build succeeded.
When trying to build 34.2.0 it failed with Unknown option: --enable-jxl. When was this option removed, and why? What are the implications?

Relevant part of the build log:

Code: Select all

 0:10.16 Traceback (most recent call last):
 0:10.16   File "/media/dragos/AllData2/Programming/Linux/Sources+scripts/PaleMoon/palemoon2026/configure.py", line 32, in <module>
 0:10.16     sys.exit(main(sys.argv))
 0:10.16   File "/media/dragos/AllData2/Programming/Linux/Sources+scripts/PaleMoon/palemoon2026/configure.py", line 24, in main
 0:10.16     sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure'))
 0:10.16   File "/media/dragos/AllData2/Programming/Linux/Sources+scripts/PaleMoon/palemoon2026/platform/python/mozbuild/mozbuild/configure/__init__.py", line 360, in run
 0:10.16     raise InvalidOptionError('Unknown option: %s' % without_value)
 0:10.16 mozbuild.configure.options.InvalidOptionError: Unknown option: --enable-jxl
 0:10.20 *** Fix above errors and then restart with\
 0:10.20                "/usr/bin/make -f client.mk build"
 0:10.21 make: *** [client.mk:370: configure] Error 1

On a related note - maybe the new Python3 build environment would try to catch such exceptions graciously and provide the user with a choice to continue with the offending option disabled, or stop the build, fix the configuration, and rebuild. This considering there may be more than one offending option, and restarting the build process N times just to find yet another bad option might be at least annoying and time wasting.

[biopsin]

I confirm breakage with jxl enabled.

[jobbautista9]

--enable-jxl is no longer a valid mozconfig flag, because JPEG XL support is always built and that flag has been no-op for a pretty long time now. You should remove it.

[Drugwash]

--enable-jxl is no longer a valid mozconfig flag, because JPEG XL support is always built and that flag has been no-op for a pretty long time now. You should remove it.

Yeah, after removing that option from .mozconfig half-time in the build process I noticed libmedia_libjxl being built. Now forgive me for sounding like a Vulcan but breaking the building process due to a redundant option seems... illogical. The logical way would be to add all such redundant/obsolete options to an internal list, and when any of them is encountered just notify the user about its status - do it in bold red font if necessary - and let the build continue normally.

I wonder, would that option's counterpart ( --disable-jxl ) be available and valid? Who knows, maybe someone would want/need it for whatever reason.

[Moonchild]

breaking the building process due to a redundant option seems... illogical. The logical way would be to add all such redundant/obsolete options to an internal list, and when any of them is encountered just notify the user about its status

Configure does exactly that.

0:10.16 mozbuild.configure.options.InvalidOptionError: Unknown option: --enable-jxl

it halts the build process at the first stage (very early in the build process) with the message that it's an invalid option.
This has been the way the Mozilla build system works for a long time. Invalid configure options are fatal.

I wonder, would that option's counterpart ( --disable-jxl ) be available and valid?

it's not. And by treating invalid options as fatal, you aren't left guessing if your mozconfig options are actually doing anything or not. If you just let the build continue (most people won't view the compile output) then you get confusion "why is my config option not working...?"

You might think it's a "bit harsh" to do it that way but there is no real option to do it another way other than adding a bunch of complexity to the build system to have "depreciation" stages. And that's just overkill for a single application.

[Drugwash]

This has been the way the Mozilla build system works for a long time. Invalid configure options are fatal.

Maybe it's time for certain things to change, seeing the Python environment already is.

And there's a difference - maybe too subtle - between invalid and redundant/obsolete.
Unknown/invalid options would be those that have never been implemented, or are simply typos.
Redundant/obsolete would be those that at some point in time were valid, and then were not. They are/were known.

Since many/most? people that build by themselves may not [always if ever] be aware of all changes made to the entire code base, notifying them during the build process that something is no longer valid but doesn't break anything - as opposed to breaking the build because something has never been valid - would be at least kind to them in my humble opinion.

In order to build today I had to close all applications (except for the mail app) and use BleachBit to clean memory, because there's not much available for such project and it needs contiguous memory. Breaking the build process lead to me running the file manager to find the configuration file, then run a text editor to modify it, then close them both and run BleachBit again. What a wonder to see the same error and breakage again... because I had accidentally modified the wrong file. So open file manager again, open text editor again, modify the right file this time, close both apps, run BleachBit again to clean memory for the third time. Finally the build went through in 139:29.21 for building + 4:26.74 for packing. Is this just a bit harsh for a redundant option...?

Would it be easier and more useful for anyone if with each new release a list of valid config options would be posted on the Release Notes page so that self-builders could take note before starting their own build? I suppose not. Adding to a list - even a separate module to be imported - and checking against that list while the Python system already does a validity check, would be easier in my opinion. Not much complexity to add a string to a list of strings (only when necessary) and perform an additional check. Maybe @athenian200 could look into this and provide his own opinion on the matter as long as he's working on the switch to Python3.

[Moonchild]

No, it has already caused confusion where people explicitly indicate non-functional mozconfig options and them not doing anything, so making sure to remove them from the list of (currently!) valid options is what should happen. Adding a bunch of extra work documenting a list of options every release is quite nonsensical busywork and I won't do it.

It's not that difficult. If configure fails with an "unknown option" from mozconfig, then it's time to remove it as it obviously won't work. "Do it now, not later/forget about it"

[athenian200]

Maybe @athenian200 could look into this and provide his own opinion on the matter as long as he's working on the switch to Python3.

Since you asked for my two cents, here it is...

I will admit, it was a slight nuisance to have to remove --enable-jxl from all my .mozconfig files I have scattered across build environments (same with other old options that got removed), but then again I'm also not building in an environment where opening a text editor in the background during a build would cause issues. It's basically muscle memory for me. And I also get the other side of it, that we don't want tons of redundant options left lying around and bloating the size of the .mozconfig. Though really, the more concerning thing in my mind has actually been people assuming libjxl is broken now because the option to enable it was removed... not realizing it's built by default now.

Like, the one thing to make clear is that for most people, the "invalid option" message basically is their notification the option was removed. Though it depends on them knowing how the build system works, and also assumes they aren't running on a RAM and hard-drive constrained environment where running a file manager or a text editor would take up too many system resources. It usually isn't that hard to get a build started up again if it stops. I will offer one tip about editing your .mozconfig that might help a little, though. You should run the editor from the console window, never fire up a file manager just to find it. If you just type vim .mozconfig or emacs .mozconfig in the same directory as you started the build from, you'll open the right file every time, no file manager required. Vim is a console text editor and very light on resources (was designed for old terminals), so it might be worth learning if your environment is constrained.

The only idea I really have that could work for this, is to build on what Basilisk-Dev did for his browser... vendor a default .mozconfig file that gets copied in as the user's .mozconfig if they don't have one already, and then use that instead of relying on the user to have their own local .mozconfig up-to-date.

So basically, we'd vendor a default .mozconfig with the application, and treat that default .mozconfig the way CLOBBER is treated now. Basically, if that file gets changed, warn the user the browser's default .mozconfig was changed and that they should double-check their local configuration against the official .mozconfig before trying to build, just like we warn them to clobber if CLOBBER is touched. It should be easy enough to do, and wouldn't require too many changes to the build system. But it would mean every time we touch the build options, we'd have to make sure we remember to update that default .mozconfig provided with the browser, or the same issue would still happen.

I genuinely wonder how often this is a problem, though... if it's mostly the resource-constrained build environment that makes this an issue, or if other users have issues around this? I personally think it's fine the way it is, but also would understand if we want to improve on the situation a little. I think it's something to save for a later date if we do want to change it though, since I currently have my hands full making sure the Python 3 build works across multiple environments. I still have to go through those Linux patches we got from a Debian user, investigate a non-fatal Powershell nuisance on Windows, and figure out why NetBSD isn't working (just got an e-mail about that).

[Alpha1_2]

Hi

The default does not work and changing it to "false" does the same with handling Cloudflares image resizing; still keeps looping.

As stated in Implementation notes:
CloudFlare offers an image resizing service to its clients, which takes a complex string in the URL to control the resizing process. The workaround implemented in this version will treat anything after /cdn-cgi/image/ as opaque path data (on all websites, considering the wide-spread nature of CloudFlare as a CDN, on many top-level domains). Without this workaround, image resizing like this does not work and results in HTTP 403 (forbidden) errors.

This workaround does break with our normal way of parsing URLs, so if it causes trouble with sites with this particular path prefix, try changing the preference (to false, to disable this workaround) and see if it helps, and let us know (on the forum or repo).

Regards
Alpha1_2

[jobbautista9]

Please don't hijack other people's threads. The 403 issue with Cloudflare's image resizing CDN is different from the looping problem with Cloudflare's captcha. While both are pretty much Cloudflare's fault, the former can be workarounded as seen with this update and the latter is purely on Cloudflare to fix (we don't know the exact details of how they gatekeep browsers)

[Drugwash]

it was a slight nuisance to have to remove --enable-jxl from all my .mozconfig files [...] You should run the editor from the console window [...] if it's mostly the resource-constrained build environment that makes this an issue [...]

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.

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.

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.

Is this overcautious? Maybe, but given the situation it's the only alternative. See the similar crash reports with Nuck-TH's builds recently - who's to blame, Moonchild? No, the actual builder, Nuck-TH. So, who would I ask for help if my own build would crash? Myself and only myself. That's why I try to do it by the book as much as possible.

If my hardware and software were compatible with the official builds I'd use them, end of story. But the CPU is non-AVX, and the OS is "ancient", can't provide the necessary libraries. Neither can Nuck-TH's builds. So I either build it myself in this "tight" environment (only 8GB RAM, SSE2 CPU) or forget about the Internet.

it would mean every time we touch the build options, we'd have to make sure we remember to update that default .mozconfig provided with the browser [...] it's something to save for a later date if we do want to change it [...]

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.
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.
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.

Maybe the idea would need to be discussed in detail in order to better understand what I have in mind. I'm open to discussion whenever possible, timezones allowing. It's not an emergency or anything.

[athenian200]

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.

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.

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.

Uhh... 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:

Code: Select all

mk_add_options MOZ_MAKE_FLAGS="-j1"

Which 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.

The 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.

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.

Yeah, 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.

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.

Correct 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.

The 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.

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.

Well, 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.

All 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:

Code: Select all

cd platform
git log -- build/moz.configure/old.configure

If you do that, you will see, fairly close to the top:

commit 7fca2b8de39e9aaeaa594f814c45c7ae03267ff1
Author: Moonchild <redacted e-mail address>
Date: Sat Mar 21 11:57:15 2026 +0100

Issue #2739 - Follow-up: remove missed configure bits.

We still accepted {en|dis}able-jxl as a valid old-configure option and
there were a few leftover pref conditionals.

That 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.

EDIT:

I just did some testing with this, and what I found is that an invalid .mozconfig option fails at the configure tier, not at the build tier. So one way to avoid running into problems before you commit to a full-on ./mach build is just...

Code: Select all

./mach configure
(See if your .mozconfig is valid)
./mach build 
(After the build system gives you a thumbs-up and confirms configure is complete.)

Sorry if this post is confusing, I'm just tossing out ideas to see if something clicks...

[Drugwash]

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.

Maybe, maybe not, I wouldn't know what other people are thinking. As I read it around this board a few times I took it as a precaution.

there's always this option: mk_add_options MOZ_MAKE_FLAGS="-j1"

I know, it's present in my .mozconfig with the difference that i allowed for 2 threads instead of one as I saw total RAM usage would reach at most 7GB all in all during build (without other "hungry" apps running). It's already taking more than two hours as is, with a single thread it'd take forever. I'll be 60 in a couple months, don't have much time to spare.

BleachBit only clears up fragmentation in disk space, not RAM.

There is an option to clear memory, at least when run as administrator/root.

Screenshot from 2026-04-09 00-53-11_edit.png

basically reboot the machine [...] Which, if anything, wouldn't make your overall concern less valid if you're having to boot-cycle the machine between build attempts

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.
And by the way, my desktop is Cinnamon 4.2 (in Linux Mint 19.2).

maybe even boot into terminal mode

Well, that's the catch: after 20+ years of MS Windows I can only think of myself as a mouse person, don't quite fancy the Terminal and working in command line. That's why vim, nano and other hotkey-based editors - and any other applications that emphasize on hotkeys - aren't really an option for me (and possibly other users too). My editor of choice is CudaText, and the file manager is Double Commander (considering I've used Total Commander in Windows since before 2000). They both have dozens of tabs open, mainly because my memory is failing day by day and I need reminders. So that makes for some unpredictable RAM usage - hence my memory clearing precaution.

doesn't the build usually stop very early with an "error processing mozconfig" or something if you use an invalid option? [...] it isn't going to waste your time by pretending it will build and then getting halfway through.

We're back at the beginning. It does stop early indeed, but precisely the fact that it stops and demands editing a file - who knows for how many times in a row! - which in turn requires several operations that may tamper with memory, is what brought this issue up. It doesn't matter much if it stops two seconds or one hour after starting the build, although if it were the latter it would definitely waste much more of user's time.

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.

No, there's no bug or regression, compilation doesn't start when it shouldn't. And the error message is pretty clear. However there's room for improvement, such as catching the exception and presenting a cleaner error message as not everyone may be familiar with Python's errors. That wouldn't solve the current issue though.

The thing that's worth noting is that your concerns are actually inverted from those of the average developer.

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.
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.

[...] the process that ultimately turns the mozconfig into parsable tokens is implemented as a very dumb shell script, not as actual Python code.

Well, that's a bit unfortunate but still not unsolvable. A shell script can still launch a Python script that could take care of the invalid tokens by returning only the valid ones that would then be parsed by the same script:
(more or less pesudocode)

Code: Select all

UNPARSED_TOKENS=...
VALID=$(venv/python "/path/to/validating/script.py $UNPARSED_TOKENS")
# process $VALID tokens.

Or maybe modify the dumb script to do the validation itself. Unfortunately shell scripts are not my forte but I'm struggling when needed. Syncing the repository and building PM and DblCmd - complete with renaming and moving to dedicated folders - are actually [semi]automated through shell scripts.

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.

I wouldn't agree to that either. A clean config is always best. All I wanted was the ability to clean it after the build is done if I considered it would be OK to let it run - otherwise there's always Ctrl+C to stop the build manually.

In your terminal, before typing ./mach build, do this:

Code: Select all

cd platform
git log -- build/moz.configure/old.configure

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)

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.
Thank you all for your input.

[athenian200]

]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.

Ah, 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.

And by the way, my desktop is Cinnamon 4.2 (in Linux Mint 19.2).

Good to know, I actually have a VM of that environment laying around already, so I can test it.

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.
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.

I 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.

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)

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.
Thank you all for your input.

Like, 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.

But 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.

I 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.

[Drugwash]

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.

Basically yes, but it's understandable considering the evolution over so many years when all that's been done was mainly patchwork (on Mozilla's part).

The idea of building a GUI for configuration and maybe tracking the entire build process would be welcome by most people I guess (me included), maybe save from those that automate even configuration files and other stuff through scripts and whatnot. Personally I didn't dare suggest something like this knowing how difficult it is (I did build a few Python GUI apps for myself). But it could ease the configuration process, and having only the allowed options at hand would definitely avoid such build breakages and other issues.
A GUI could also provide predefined configurations for most used environments (Linux/Mac/Windows, AVX/AVX2/SSE2, GTK2/GTK3/GTK4? etc), where only certain options could be tweaked within the respective frame. Much less prone to human error.
Relevant parts of the changelog could be read by the press of a button for whoever is interested. Addition or deprecation of options could be emphasized and explained in more or less details. Maybe the entirety of the current release notes could also be readily available at the press of a button.
(what i really don't like in applications generally is the bad habit of launching the browser when user clicks on Help or similar option instead of providing a local document, if Internet access is not available for any reason or the browser would disturb other running processes)

Good to know, I actually have a VM of that environment laying around already, so I can test it.

Mind you my system is unofficially updated with third-party backports and a few self-built tools and apps, including changes to some of the system files (Python and JS). You won't find GCC9 officially available for Ubuntu 18.04/Mint 19.x, nor Python 3.8+, Qt5.15, Qt6.2, Gtk4 or others. So mine is not exactly a standard environment.

It is worth noting that we usually don't deprecate more than one build option at a time [...]

I was thinking of the rare but still valid possibility that a user might get a [very] old config file from someone else or from an older build, maybe a totally incompatible version, so in that case more than one option could pop up as invalid/deprecated. That would indeed trigger repeated editing and retries, with accumulated frustration. User's fault, of course, but still.

I just comment out the old options with an # symbol in case I have to roll back to an old build [...]

I do the same, mainly not to forget about it if it's ever needed back. Memory, you know...

Looks like we agree at least on one thing: the build system needs a face lift. How and when - to be seen. I'd be happy to help if and when possible, with my limited knowledge. Oh, one thing I forgot to mention: most time my connection is capped at ~128kB/s as the monthly download quota goes away much too fast. So downloading large amount of files (such as the entire UXP code base) would take a lot of time, even loading a web page in the browser takes a while. That's why I didn't get to check out the Python3 changes you made recently. And to think that web pages loaded much faster back when all I had was a no-name 14400 bps ISA modem...

[Moonchild]

The idea of building a GUI for configuration and maybe tracking the entire build process would be welcome

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. And that would entirely miss the mark for where people build from source most, which is Linux. Which in turn would make it less of a priority because of the small percentage of users, even smaller percentage of GUI users building, and even smaller taking into account people preferring to do these things from the CLI. So who would I be building it for then? I hope you get my drift why it's not really been done.

I was thinking of the rare but still valid possibility that a user might get a [very] old config file from someone else or from an older build, maybe a totally incompatible version, so in that case more than one option could pop up as invalid/deprecated.

Then what they are doing is already a bad start: blindly copy-pasting a config they most likely don't understand, using it, not l;ooking at the build instructions posted on the website, etc.
And 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.

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,

Those remarks were primarily for building on hardware configurations that are woefully insufficient, would cause swapping and slow I/O which would trip up compilers and linkers (both on Windows and Linux). The actual cause being outside of our wheelhouse, mentions of fragmentation were "best guess" causes mentioned based on observed behaviour (e.g. build failing or being unstable, but being OK after a fresh restart of the exact same machine and configuration). 8GB is fine if you don't go overboard on parallel compilation tasks. The more of those you use, the more memory you need, but it's not 1:1; a lot depends on the linker as some parts are single-process, high memory link tasks.

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.

It was understood correctly and completely. But you are talking about "breaking the workflow" while all it would be doing is interrupting when you are assuming zero-maintenance workflows. It just isn't the case here that you would have or can assume zero-maintenance as we continue to develop. As I said already we can't start doing a whole multi-cycle deprecation development flow for each configure option we touch. Instead, if there's a change in recommended config or available options that impacts our documented build process, then those documents will also be updated. IMO you are making an elephant out of a mole hill here, wanting the build process to "never halt" depending on invalid/removed mozconfig options. While that's possible, you don't seem to understand the issue from our end with that correctly and completely: Not doing such a check would have people assume things work and then complain or be confused and want answers if they did not. The incomplete removal of the option in this very case (JXL, my bad for not making it an invalid option right away) caused exactly that as the most recent example (definitely not the only occurrence!).

So, you can either "break the workflow" for people wanting zero-maintenance while the application they are building is developing, or cause the inconvenience of having to update mozconfig when options are changed or removed as our development progresses.

[Drugwash]

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.

Someone 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.

And 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:
- it has a user-friendly layout
- provides best defaults
- it's intuitive

So who would I be building it for then?

For everybody.

Then what they are doing is already a bad start

Granted, but they are probably beginners, and in time they'll learn - if they will be helped to.

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.

Currently 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.

8GB is fine if you don't go overboard on parallel compilation tasks.

As 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?

we can't start doing a whole multi-cycle deprecation development flow for each configure option we touch.

This 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.

As 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?

Not doing such a check would have people assume things work and then complain or be confused and want answers if they did not.

I 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?

It just isn't the case here that you would have or can assume zero-maintenance as we continue to develop.

Why not strive to reach as close as possible to that...?

OK, 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.

[JayByrd]

For the record, this --enable-jxl bit me too when compiling 34.2.0. As MC said, it was caught early in the process, and I just removed that line from my .mozconfig and was back in business--no big deal.

While I understand that it might be frustrating to encounter a new build failure due to an obsolete option, silently ignoring it would not be helpful in the long run. Personally, I figure MC has enough on his plate without having to design and build an external GUI application to hand-hold people through the build process. Just my two cents...

[UCyborg]

This whole thing is incredibly fragile. Set the path to compiler / linker it doesn't like...breaks. Rename folder with obj files and value of MOZ_OBJDIR...breaks.

Visual Studio solution is still the best.

[athenian200]

Those remarks were primarily for building on hardware configurations that are woefully insufficient, would cause swapping and slow I/O which would trip up compilers and linkers (both on Windows and Linux). The actual cause being outside of our wheelhouse, mentions of fragmentation were "best guess" causes mentioned based on observed behaviour (e.g. build failing or being unstable, but being OK after a fresh restart of the exact same machine and configuration). 8GB is fine if you don't go overboard on parallel compilation tasks. The more of those you use, the more memory you need, but it's not 1:1; a lot depends on the linker as some parts are single-process, high memory link tasks.

Oh, I think I know exactly what you're talking about now. The linker issues. Linkers in particular are notorious for gobbling up RAM and not being able to make use of swap, doing everything all at once even if it's a huge library.

Anyway... if I were building on a machine with about 8GB of RAM or so, I'd likely use it semi-normally for light tasks with the build going in the background until I can see libxul getting closer to being built, and then start closing stuff very quickly to make sure libxul has enough room to link. I've always done that... never really articulated why I do it clearly (it's almost like an instinct), but I think you actually nailed it.

In other words, it's not as if the entire build is sensitive to RAM usage. There's just one part of the build, close to the end, where you have to worry more because it's linking a huge file. So, these failures early on in the build process aren't really dangerous at all. It's perfectly safe to open a text editor, a file manager, documentation, anything you need for most of it. Just make sure you're going easy on RAM usage by the time libxul starts linking.

So yeah, IMO, that's pretty much the case... it's less a "you have to close everything, use BleachBit to clear the RAM, and minimize all RAM usage before the build even starts or it's doomed," and more of a "you should probably close your web browser before the JS engine and libxul start linking so they have plenty of RAM to work with." Like, yes the linker is sensitive when linking big libraries, yes there are big libraries in the build... but it's not like the entire build is linking mozjs or libxul. It's more like one big spike that has to be accommodated carefully rather than a constant danger running throughout the process.

Granted, I will admit these kind of insights are far more obvious if you're the type of person that sometimes builds the browser 10+ times a day when working on certain things, than the type who builds it to actually use it when a new release comes out. The irony is, I rarely ever use my own self-built copies of Pale Moon... I use the official versions so they'll update automatically. I build it primarily to test my changes or other people's changes.