Update to 52esr

[dmik]

This is the latest ESR from the Firefox team so far.

This is the latest release at the time of writing: https://hg.mozilla.org/releases/mozilla-esr52/rev/FIREFOX_52_4_0esr_RELEASE

[dmik]

Vendor imported in 628bf1d, merge is ahead. I see that they already added some Rust bindings (in 3rdparty, for LIBC and other stuff), I wonder what for.

[dmik]

Also configure.in seems to have gone and python is used instead now. Merging promises to be fun.

[dryeo]

There's a H264 video decoder (encoder?) written in rust, and I believe they may have started migrating the international charset stuff to rust. The important thing is that 52ESR should build with --disable-rust without losing important functionality.

[dmik]

Ok, I see. Guessed something like that.

[dryeo]

On 10/09/17 12:28 PM, Dmitriy Kuminov wrote: Also |configure.in| seems to have gone and python is used instead now. Merging promises to be fun.

On the other hand, build times are supposed to be much improved with the new build system.

[dmik]

These insane people still store sqlite3 sources flattened to a single file. It's current size is 7M and the upstream diff between 45esr and 52esr is alone 3M. Of course it's absolutely unmanageable in terms of resolving conflicts (which each update inevitably brings). I guess I will better update our standalone sqlite3 port from 3.7.2 to 3.17.0 (current FF requirement). I don't think it should be very difficult. At least not more difficult than to reapply all OS/2 patches to this flattened catastrophe (as it's impossible to merge through conflict solving, of course — conflicts are 1000s line long).

[dmik]

And they changed FFMpeg integration again. They are doing it in each update — in an incompatible way, of course.

[dmik]

Also, there is some change in js/src/asmjs which was renamed to js/src/wasm (OS/2 code goes slightly after Mac code there).

[dmik]

Also, they're not using configure for nspr and sqlite builds (but that should perhaps not affect us given that we use external versions of them).

[dmik]

I've finally merged the changes in. Most conflicts are solved but not all. Top things to work further on:

• As old configure.in was renamed to old-configure.in, all OS/2 patches to it were lost (same for js/src/configure.in). It's better to still have them so I will have to reapply them clean to this new file.

• Sqlite (db/sqlite3/src/sqlite3.c) was updated from 3.7.2 to 3.17.0. The file is 7M and diff is 3M, conflicts are 1000 lines long so I had to give up with merging and took the vendor file. All OS/2 patches need to be re-applied clean but this will be done in a dedicated sqlite3 repo (http://trac.netlabs.org/ports/browser/sqlite) as it makes much more sense. Once it's done and works, Sqlite code will be removed from our FF fork completely (to force any further needed updates to go to the separate repo as well). BTW, I plan to remove in-tree NSPR, NSS and all other libraries we maintain separately as well (for the same reason).

• FFmpeg integration in dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.{cpp|h} was rewritten hardly again. I have to re-port it to OS/2 clean so I took the vendor version for now.

• Same for services/crypto/modules/WeaveCrypto.js — too many changes to resolve while merging, has to be re-ported to bring the same idea.

• A lot of other small things here and there which I noted down but they are too numerous to be listed here. A build will reveal most of them.

[dmik]

It seems that old-configure.in before renaming so the OS/2 patch simply does not apply. Many things were removed to the Python level it seems (like detection of HOST_OS_ARCH and friends). I have to port the new Python configure and its helper files then.

[dmik]

There are problems everywhere it seems: mach is hiding process output so that a failure in client.mk can't be seen. And client.mk itself does some strange evaluations when reading the mozbuild file. It looks like they changed quite a lot.

[dmik]

I fixed a small python problem in 15c70d4 but now I'm getting a weird failure when running mozconfig.py: sys.executable (i.e. the Python EXE) is D:/Coding/mozilla/master/ there. Something tells me it may be related to virtualenv...

[dmik]

It's not virtualenv (not so far at least). Looks like a bug with sys.executable detection in our python. This works:

D:>python -c 'import sys; print sys.executable'
C:/USR/BIN/python.exe

This doesn't:

D:>python2.7 -c 'import sys; print sys.executable'
D:/Coding/Tests/python/

Testing shows that python.2.7 simply assigns the cur dir name to sys.executable. Strange.

[dmik]

Yes, hacking around the above brings virtualenv problems (expected). It's been a long time since we fixed it last time.

[dmik]

Note that the problem from #240 (comment) is fixed within http://trac.netlabs.org/rpm/ticket/277.