Pale Moon forum

So I've heard a number of complaints lately about how the current UXP build system is creaking at the seams. One user noted that it requires Python 2, which is becoming less available on Gentoo and thus building UXP applications is getting harder. One core developer even referred to the build system (relatively) recently as a "ridiculous hybrid of two different configure routines and two and a half build file types."

So I'm interested, from the perspective of a core UXP developer: What build system would, hypothetically, be ideal for UXP, if it were possible to convert all the old build files over to any new build system in a reasonable amount of time?

Let's take Meson as an example that comes to mind readily. If someone were to come to the core developer team and provide a totally new build system based on Meson, besides the testing efforts involved, would you, the core team, likely accept such a contribution? Or would it be sort of "Well, I'd sign off on this, but Meson isn't my cup of tea?"

Thank you for the consideration here. I look forward to any answers I may receive.

No.

The build system isn't really "creaking at the seams" - Python 2.7 is the only dependency that's become questionable at this point, and Gentoo is just one flavor of Linux, and so far one of the few that have dropped support for it. I'm speculating, but I think it's possible to migrate the Python code in the build system to Python 3, or perhaps to a fork like Tauthon.

I can't speak to the feasibility of other build systems, as I don't have much experience with them, but I can say that any migration of any kind will be a long and complicated operation.

Plain make.

Ascrod, as we have discussed before.. mozbuild and mozpack may be able to realistically modified to work on python 3 but mozconfigure is a whole different animal of major interdependant dependacies and otherwise incomprehensible code mangled together seemingly by interns under the direction of a morons.

Also, as we have discussed before, elemination of most mozconfigure logic is amoung our goals but there are other parts of the top level configure logic that is much more difficult to reverse back into its autoconf and m4 modue form.

For mozbuild, mozpack, xpidl handling, webidl handling, ipdl handling and such it is hard, very hard to tear those things apart from the mozilla python build system to go back to pure autoconf especially since a lot of the work in the build system has no physical representation anymore in the backend objdir.. Mozilla sometime between 24 and 52 started storing huge swaths in memory and not as representations translated to makefiles to be taken back in during the build process.

Without knowing exactly what the build system generates or does for every last piece of everything.. Just switching to another completely different system is out of the question.. and there would likely always need to be AT THE VERY LEAST mozbuild and mozpack because one has to realize that beyond the three forms of idl we have to process we also have to consume google gyp horseshit and also have to do the mozilla things like chrome manifests n shit too.. Not to mention get nspr and nss to build and of course js and much more i can't remember or don't know yet.

So completely different build system, reverting to pure autohell, and porting to python 3 while may not be technically impossible, I can say with all certainty that today it is practically impossible.

It is not something one man or a few people can do and it is not something we have much time for even for the bits we want to do.. We also know the community is basically bust on something this complex when they can barely deal with extensions.

As for Python 3, forget it for at least the foreseeable future. It is LITERLY EASER TO JUST COMPLE PYTHON 2 OR FIX ANY FUTURE BUILD ISSUES WITH IT THAN IT IS TO CHANGE THE BUILD SYSTEM OF UXP. Not to mention the gentards compile source code like a crack addict smokes crack.. I don't see how any gentoo user can bitch about having to compile or fixcompile Python 2.

With that.. Let me reiterate my original answer:

No.

The current version used for what's left of autoconf is 2.13, which is available only due to mozilla, so it's not really just python the problem.
Because autoconf 2.13 was released in 1999 and even debian wants to remove it, I wonder how UXP will fare when Firefox will stop having it as a dependency.

vannilla wrote: ↑

2020-08-03, 11:03

I wonder how UXP will fare when Firefox will stop having it as a dependency.

You mean if it will make it more difficult for unofficial third party builds with crazy configs to be made by random people who think building yourself is always better than letting the original team do it and test it and make it available for everyone as a binary? Yes, absolutely.
Will it make a difference for us? No.

To answer the topic question: I don't know what the ideal build system would be, aside from a cleaned up version of what we have (and getting rid of moz.configure nonsense). There are no shortcuts here. There isn't a single solution out there that can deal with the vastly different configure requirements we have in various parts of our tree. it simply does. not. exist.

Even if it did, it would be a massive task to convert what we have to whatever system it would be. I'm talking months of work, thousands of configuration and build files, not to mention how everything has to be tested individually AND in context.

Autoconf can never be upgraded as the newer ones are fundamentally incompatible with those parts that we use that are still autoconf.

Like Moonchild said, not our problem. Indeed, buildability of the source code by you has nothing to do with us and no open source license requires that everyone is able to physically build such code.

I find it funny that physical buildability is assumed when not one license says that is a right expressed.

Well Moonchild, thanks for the civil and to-the-point answer there.

Remember: I personally don't believe it's likely that UXP will be ported to use some other build system of any kind yet. I just wanted to know, if someone hypothetically came to you and the core team and said "Here's the revamped build system, it uses X [not the windowing system], take it or leave it," would you even consider taking it, or would you immediately leave it?

That's all I wanted to know. Thanks again.

BTW, @vannilla, it's totally true that I was only giving Python as an example.

The Squash wrote: ↑

2020-08-03, 16:08

I just wanted to know, if someone hypothetically came to you and the core team and said "Here's the revamped build system, it uses X [not the windowing system], take it or leave it," would you even consider taking it, or would you immediately leave it?

And I pointedly did not answer that question.

New Tobin Paradigm wrote: ↑

2020-08-03, 14:41

I find it funny that physical buildability is assumed when not one license says that is a right expressed.

I'm sure that if "Let them have the source but not the ability to build it" ever became a corporate strategy to effect software that is free in name but not in spirit, Stallman would come up with a GPLv4 to assert what he sees as users' god-given right to build all free software themselves. Of course there's a huge difference between actively hindering custom builds and just not going out of your way to facilitate them, but I actually don't find that assumption all that unreasonable, even if it is technically incorrect.

My personal and irrelevant opinion about build systems is: the simpler the better. I believe all this auto* bullshit is part of the problem and not really the solution to many real-life problems. Just assume a reasonable build environment (documenting what you expect) and bail if it's not there.

Good thing we are under the MPL then, huh?

Of course. The GPL is an abomination, but it does represent a significant point of view on what it means to be free software.

The main point I was trying to raise was more on the lines of "I wonder what will happen when the developers will have to update the systems they use to build the binaries they distribute officially and they find out the software they need can't be installed anymore".
Though yeah, it'll take another 20 years before then, that's a given. Still, it's food for thought.

Well, here's the big reason why we can't migrate off of Python 2.7 easily...

https://github.com/MoonchildProductions ... idl-parser

We have an entire IDL compiler that isn't WebIDL written in Python 2.7 syntax. The only alternative to that is hunting down and fixing up ancient libIDL compiler that hasn't been maintained in years, or else trying to remove the dependency on generated code and go back to hand-written XPCOM bindings.

Realistically, that would seem to mean we're dependent on Python 2.7 until at least that one issue is dealt with, and there's probably more just like it. Our Python code does more than just build, it pre-processes, it generates code, etc. That can't all be done with simple Makefiles or shell scripts.

Now, I could also reasonably ask why distributions aren't carrying a package like this one:

https://github.com/naftaliharris/tauthon

There's a perfectly good fork of Python 2.7 that attempts to be compatible with Python 2.7, and also allows the use of some Python 3.x features that don't conflict with the way 2.7 works. Yet I haven't seen a distribution yet that has it in their repo. So I would say our ideal build system would be Linux distos adding Tauthon to their repos and letting us migrate to that instead of Python 3.

It is on the table.. But there is MORE than just xpidl, there is webidl and dom bindings generation, there is ipdl shit.. Lots o shit.

Codegen is ONLY the most obvious part though.

athenian200 wrote: ↑

2020-08-03, 20:02

Well, here's the big reason why we can't migrate off of Python 2.7 easily...

https://github.com/MoonchildProductions ... idl-parser

We have an entire IDL compiler that isn't WebIDL written in Python 2.7 syntax.

I'm still only a layman to UXP, but I'll note that this IDL compiler is only a few thousand lines long. That's not going to be the hard part to port, from my perspective. The mozbuild files I think will be harder to port; there's just so many of them.

Not saying anyone should jump on it; but I am saying that it's not a significant part of the whole "outdated build system" landscape. Autoconf 2.13 and the mozbuild files are the main parts which are, okay, not creaking at the seams but at least not following the times...

I know somebody will have wrote: If you want to follow the times, hop on the Google Chrome ******* **** bandwagon. If you want to stay with us, then stand with us.

...yeah, I couldn't give an iota about following the times myself. But the fact is if you stand still in time like a deer in the headlights then you're eventually going to get run over by the proverbial tank driving down the road which is the rest of the software industry. Ask me how I know this.

Again, I am not asking anybody to do this, I am probing the community core to see if they would have moral or philosophical objections to a new build system, even just a slight revamping of the old system.

BTW, don't mistake what I just wrote for hard feelings.

The "community core" is not the ones doing the work. You have your answers. Now piss off.

athenian200 wrote: ↑

2020-08-03, 20:02

Now, I could also reasonably ask why distributions aren't carrying a package like this one:

https://github.com/naftaliharris/tauthon

I was wondering that too. There isn't even a .deb packagebor tarball for it, so I guess the only way to use it currently is to build it from source first. Getting UXP to pick it up in place of Python is a whole other matter.

New Tobin Paradigm wrote: ↑

2020-08-03, 14:41

Like Moonchild said, not our problem. Indeed, buildability of the source code by you has nothing to do with us and no open source license requires that everyone is able to physically build such code.