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

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