Platform Development • Re: I created a Python 3 port of UXP out of boredom...

Semi-related, but with Python 3 slowly creeping in I wonder if Autoconf 2.13 can also be replaced somehow. I know how to use Autoconf and can migrate it over newer versions or even remove it entirely, but I can't figure out how it's used by the build system at all.

Oh, actually our codebase apparently vendored Autoconf 2.13 a long time ago, so we only need m4 to build now. Autoconf back then was little more than a series of m4 macros. So we actually don't need to get rid of it, and I think MC told me once he wanted to keep it.

The main reason for keeping it is so that UXP applications can still rely mostly on Makefiles and shell scripts without having to worry about Python too much, if they prefer. The setup we have basically confines Python to UXP and lets applications pass in shell, mozconfig, and Make directives, with maybe a few Python stubs. I believe it is also responsible for version checks in old-configure, and basically turning old-configure.in into an old-configure file.

But yeah, if we're talking theoretical we could remove Autoconf if we wanted, it's basically just macros. Python already does the heavy lifting in the build system, and Mozilla did it upstream eventually. In all honesty, I get the temptation, my Python 3 port actually would have been easier if we didn't have to keep Autoconf... getting Python 3 to interface with Autoconf (particularly on Windows MSYS1) was almost more of a pain than updating the code more generally, and nearly stopped the project before it got started. The Python 3 bundled with MozillaBuild worked so poorly that I wound up having better luck with a standard Windows build of Python 3 forced into MSYS1 via PATH manipulation, which was a desperation move made early on that I kept building on.

https://repo.palemoon.org/athenian200/U ... heckcmd.py

I wound up replacing several raw subprocess.Popen calls with this wrapper just because of how much I was having to normalize newlines and clean up the mismatched assumptions. Python 2 was assuming ASCII, MSYS1 was assuming ASCII, and a lot of encoding issues were avoided originally by treating everything as raw bytes... but Python 3 is a lot more strict about treating text as text and bytes as bytes, and thus keeps translating between UTF-8 and CP1252, and sometimes I have to normalize newlines from Windows to Unix format when dealing with terminal output because Python knows it is running on Windows and tries to use DOS-style newlines, but MSYS1 expects Unix style line endings I think, so all kinds of guarding against wrong encodings being passed around and erroring out is now needed. Still, the task wasn't insurmountable, programmers have been dealing with these old DOS/Unix newline issues and Unicode/ASCII issues for decades...