Re: Firefox 38.8.0 Beta 7 released

Dmitriy Kuminov wrote:
> On 2016-06-01 05:33:28 +0000, Dave Yeo said:
>
>> The options that you pass to configure, I assume that you added
>> something like --with-system-nspr and --with-system-nss.
>
> Yes this is what I now do.
>
>> Ideally they
>> should be in a mozconfig as configure will load options from it.
>> Perhaps even added to browser/config/mozconfigs so that anyone running
>> make -f client.mk or python mach build will end up with a working
>> browser. Not sure how much work this would take.
>
> I get your idea. The thing is that in our workflow such build details
> live in RPM .spec files so there is no need to store them in the app
> repo. But since there is no .spec for firefox yet, you basically don't
> have access to them. Except that you have them in the Wiki (just updated
> it with my latest set of switches used to build 38.8.0):
>
> https://github.com/bitwiseworks/mozilla-os2/wiki/Developers

OK, I'll note that by having the configure options in a mozconfig means 
just running ../configure rather then passing the options and exports 
can also be added. Less chance of a typo and easier instructions for others.
I see your still targeting i486. I'm targeting i686 and tuning for 
generic, which may benefit AMD more.

>
> I will consider looking at client.mk again but I personally don't like
> yet another level between me and makefiles.

I note that Fedora's RPM spec file creates a mozconfig and then uses 
client.mk to build. Another advantage of client.mk is it takes care of 
all the autoconf213 configures, of which there is 4 when building SM or 
TB. The spec also uses mach to run the tests.
Client.mk seems to work fine here, mach clobber is good for cleaning the 
object directory while mach build just calls client.mk.

>
>> Fixes to Firefox.exe, maybe anything under browser and definitely
>> anything under browser/app should be considered for the other apps.
>> Yesterday I added your fixes for commit
>> ec3cf36722a29f11616c454ebd9c4653e7b5b603 (Report error code and faulty
>> module name on XUL.DLL load error) to nsMailApp.cpp and nsSuiteApp.cpp
>
> Okay we should indeed share it across apps. Too pity Mozilla has
> somewhat ill source code organization in this regard causing code
> duplication and multiple maintenance...

Things have improved, Comm-centrals configure basically just calls 
Mozilla's configure now instead of mostly duplicating it along with 
simplifying CCs build and config directories. The duplication is mostly 
in the individual app directories.
The TB and SM maintainers were trying to get Comm-Central merged into 
Mozilla-Central but that was rejected along with a blanket statement 
that Mozilla developers can't spend _any_ paid time on Comm-Central and 
basically have orphaned Thunderbird (and SeaMonkey) so right now they 
seem to have forked Mozilla-Central, which if the OS/2 fork of Mozilla 
survives past 45ESR could be a problem.
Past 45ESR, they're making Rust a requirement, which sounds like a bitch 
to bootstrap as most versions, including point releases can only build 
from the previous version, something like 31 steps required to bring it 
up to date, and that's after porting LLVM.
They're also finally ripping out autoconf so lots of build changes after 
45esr.

>>
>> I try to keep up on following progress on Github but all weekend Github
>> didn't load here and this happens quite often.
>
> I see. I don't experience anything like that here.
>

Yes, its weird. Some-days everything loads fine here, other days quite a 
few sites such as Github, Wikipedia and others just time out.
Dave