Browser Development • Re: 34.2.0 build failed, --enable-jxl unknown ??

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.