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

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.

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:

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:

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