92127 - change win32 automation to do static builds

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Jon Granrose]

From email, cathleen wrote:

So, all the static build support is landed on the trunk for win32.  It's ready
to be turned when granrose is free from RTM builds.  Even installer should work too.

Build flags we need to turn on win32 static build are:
SET MOZ_STATIC_COMPONENT_LIBS=1
SET MOZ_NO_ACTIVEX_SUPPORT=1
SET DISABLE_TESTS=1

To generate installer,
run build_static.pl  in xpinstall/wizard/windows/builder
it will pick up the right packager file (packages-static-win) to use.

I think the plan is to make both static and dynamic (current world) builds for a
while, to do some comparison testings, until we are satisfied with static build
results (functionalities, stability and performance) then we can decide which
binary to ship.  Will it be in time for 0.9.3??  We really do hope so, but won't
know for sure till we start getting official builds.  

BTW, There is no plan to kill dynamic build system, even if we do decide
shipping static builds, because lots of people are still hoping that's supported
for the ease of development.

Comment 1

[Jon Granrose]

We should also have a tinderbox set up that is doing a clobber static build,
which brings us to resources.  We don't have resources right now to do both
static and dynamic win32 release builds.  We would need at least 2 additional
PCs (ns & mozilla clobber, 2 more for ns & mozilla depend would be better) to
cover both static and dynamic.  For right now we'd need to pick a build type for
the official builds and have the release builds and tinderbox do those builds. 
Then if additional tinderbox systems become available we could set them up doing
dynamic builds, but the priority from the build team is always going to be
whatever Netscape is releasing.

Comment 2

[Cathleen]

adding mcafee.

mcafee is suppose to have tinder box setup for static build already, I think. Is
that ture mcafee?  Can we leverage that?

Comment 3

[Chris McAfee]

I need more hardware to have a dedicated static build tinderbox.
It's a two-line mozconfig setting, easy.  Probably something
similar for windows.

Comment 4

[Daniel (Leaf) Nunes]

did we ever get static test builds? we should be doing those before we make 
everyone use them.

Comment 5

[Chris McAfee]

I agree with leaf, we should spin both versions for at least a few days
before making the switch.

Comment 6

[Cathleen]

I've made several builds tested on my machine, and everything looks good.  It's
good to go.  I have not done extensive funcationality tests though, and that's
why we need to start getting official builds when possible.  :-)

Comment 7

[Daniel (Leaf) Nunes]

i have a better idea... we do test builds that are tested on a machine *not* 
used to produce the build. *then* we force everyone to use the static build. 
I'll even build from the same tree, so we'll know if problems stem from 
static-buildness or not.

Comment 8

[Cathleen]

sure, building from the same tree will be excellent, in fact would be ideal.  :-)

forcing..., means there is still a way for people to get dynamic build for
performance comparison testing right?

Comment 9

[Jon Granrose]

leaf - I don't understand what you mean by using a system not used to do the
builds, but at the same time using the same tree.  I thought this would just be
an option to the automation that we would start out disabled, and then enable it
by default after a few days of testing.

cathleen - we'll probably deliver static builds and dynamic builds for a few
days, but once we're confident the static builds work and that's what we want,
we won't produce release dynamic builds any longer.  We want everyone using
whatever type build we're going to be shipping.  So if anyone wants to do
comparison testing after that they'll have to produce their own dynamic builds.

I fully expect the dynamic builds to be completely broken due to packaging
issues within 3 months of switching over to static builds.

Comment 10

[Cathleen]

> cathleen - we'll probably deliver static builds and dynamic builds for a few
> days, but once we're confident the static builds work and that's what we want,
> we won't produce release dynamic builds any longer.  We want everyone using
> whatever type build we're going to be shipping.  So if anyone wants to do
> comparison testing after that they'll have to produce their own dynamic
> builds.

that's cool with me!  :-)


> I fully expect the dynamic builds to be completely broken due to packaging
> issues within 3 months of switching over to static builds.


:-p  yup...

Comment 11

[Daniel (Leaf) Nunes]

my comment was targetted at the extensive testing done by cathleen on the 
machine she used to build. It's better to build on a machine, and see if the 
build (packaged) works on another system (the smoketester's, for instance).

you're right that packaging for the dynamic build is just going to die pretty 
quickly after we switch to doing static builds.

I wonder how smart-update is going to work if we only have big globs to update, 
instead of smaller, more easily downloaded components? 

Comment 12

[Cathleen]

> I wonder how smart-update is going to work if we only have big globs to update, 
> instead of smaller, more easily downloaded components? 

componet install still works.  we pulled mail out of the main .exe, and put all
dlls into one mail.dll.   also, on win32, js, xpcom, nspr, xpinstall and libjar
are built as dlls not linked into main mozilla.exe binary.

additional stuff in commercial tree are left alone, except main browser stuff is
linked into the main .exe

performance gain we saw back in June was based on a build that has *everything*
linked together into 1 executable... dut to the fact we still need to support
component intalls, things are broken out a bit.  mozilla.exe is about 6MB now,
mail is around 1MB.  It would be interesting to see what number we get again.

Comment 13

[Daniel (Leaf) Nunes]

i knew about the component breakouts... but wasn't there the idea that we could
replace individual dlls? a pipe-dream, maybe :)

Comment 14

[Daniel (Leaf) Nunes]

automation patch on the way. we might be able to do test builds this afternoon ;)

Comment 15

[Daniel (Leaf) Nunes]

Attachment: introducing --enable-static automation flag

Comment 16

[Daniel (Leaf) Nunes]

can i get a witness to this? r=?

Comment 17

[Jon Granrose]

leaf - what about

SET MOZ_NO_ACTIVEX_SUPPORT=1
SET DISABLE_TESTS=1

I don't see them being set in the automation anywhere.  And I'm assuming that we
don't need build_static.pl and that just running pkgcp.pl on the new
packages-static-win file will set up what it needs to makeall to generate the
xpi files?

Comment 18

[Daniel (Leaf) Nunes]

damnit; there's already:

$ENV{MOZ_ACTIVEX_SUPPORT} = "";

Which i may be incorrectly presuming does the same things as 
MOZ_NO_ACTIVEX_SUPPORT=1

And i thought we already set disable tests for the regular build; but it looks 
as if we do not. new patch on the way.

Comment 19

[Daniel (Leaf) Nunes]

Attachment: add the environment variables i thought we already had.

Comment 20

[Daniel (Leaf) Nunes]

and to answer your other question, yes, the only difference (other than 
whitespace) between build_static.pl and build.pl is the packages file it uses, 
so the change i made to the automation is equivalent and sufficient.

Comment 21

[Jon Granrose]

looks good to me.  thanks for the quick turnaround, leaf.  r=granrose.

Comment 22

[Daniel (Leaf) Nunes]

checked in. i'll do a test build when the tree opens.

Comment 23

[Ken]

Jud Valeski asked me to add this for embeddors. Currently, the static build 
process requires mailnews. Can we make the process compatible with the 
DISABLE_MAILNEWS setting?

Comment 24

[Chris Waterson]

Filed bug 93100 on that issue.

Comment 25

[Jon Granrose]

so are we holding off on resolving this until we resolve the win32 static build
performance issue?

Comment 26

[Daniel (Leaf) Nunes]

I'm resolving this, because this bug (make the automation be able to do static
builds) is fixed. Whether we move to it as the default is a separate issue.

Comment 27

[Jon Granrose]

verified.