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

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.