87004 - make xpinstall build separate in STATIC build

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Cathleen]

Comment 1

[Cathleen]

Attachment: 1st cut to make xpinstall build as a seperate dll

Comment 2

[Cathleen]

now need to test it to make sure it actually works!  :-)

Comment 3

[Cathleen]

Attachment: latest patch, everything should work!

Comment 4

[Cathleen]

thanks to dveditz's help on resolving the last glitch in libjar.  :-)

Comment 5

[Chris Waterson]

Put a comment in modules/libjar/makefile.win to explain why you're |!undef|'ing
(lower case for the makefile directive, please!) MOZ_STATIC_COMPONENT_LIBS.

I don't think the changes in xpinstall/stub are necessary. (If they are, it's
probably a bug in XPCOM -- the static component loader should be able to deal
with the fact that there are no static components defined in the module.)

Also, let's make sure that the new nsMetaModule_xpinstal.cpp.in looks right...

Comment 6

[Cathleen]

Attachment: nsMetaModule_xpinstal.cpp.in

Comment 7

[Cathleen]

Attachment: newer patch, has everything including minor changes and new files :-)

Comment 8

[Cathleen]

latest patch...
* changed to lower case !undef in libjar makefile, and added a comment
* changed nsMetaModule_xpinstal.cpp.in to have it's own CID and modified all 
  strings to refer to XPInstal
* verified that changes are still needed in xpintall/stub, without those changes, 
  installer won't work, so keeping those changes
* build_static.pl a perl script to build installer, that uses packages-static-win
  packaging file instead

Comment 9

[Chris Waterson]

> * verified that changes are still needed in xpintall/stub, without
>   those changes, installer won't work, so keeping those changes

Hmm, that's weird. What happens? Does it the static component loader freak out?
If so, we should fix that...

> * build_static.pl a perl script to build installer, that uses
>   packages-static-win packaging file instead

Do we need a whole new perl script to build static? Or could that be done with
just a switch? (I didn't even look at the original perl script, just curious...)

The rest of the changes look great.

Comment 10

[Daniel Veditz [:dveditz]]

New files should use the Mozilla Public License header, not the Netscape Public 
License. Netscape folks have been told to do this since the 1.1 license was 
released and the bulk of Netscape's special privileges in the license expired.

I'm concerned about the number of "?" files at the top of your diff -- those 
indicate files in your tree that aren't known about in the CVS tree. Generally 
they indicate new files which should have been included in the diff, although 
some of them appear to already exist so it may simply indicate something is 
really messed up with the cvs information in your tree. Either way they don't 
give me a warm fuzzy about approving this patch.

ren8dot3.exe should be removed from the package lists. We should take it out of 
the branch builds too.

I, too, don't like the changes made to xpistub. Something's wrong that will 
make life hell for anyone trying to make an embedded static build.

You could try another approach and do the same thing to xpinstall you did to 
libjar -- undef the static build define to make it an old-style component. Then 
you don't need all the "meta" changes.

Chris: yes, unfortunately we do need a copy of the build script. We had a 
long-ago bug to generalize the packaging system, but it was never a high 
priority to mgmt because the current system was "good enough". Some thoughts 
are in bug 22062

Comment 11

[Cathleen]

static component loader seems to fail if the patches under xpinstall/stub are
removed... this is a problem.  I'll need some help to resolve this issue. 
question is should I check in those work around in xpinstall/stub in the mean
time?  

I also tried changing xpinstall to use libjar approach building xpinstall as
dll, and it also works too.  Should I use this undefing method or the my current
META_COMPONENT and modules/statimod changes?  any preference?

Regarding those "?" files in my diff, files under modules/staticmod/ and
xpfe/bootstrap are generated files from static build.  Those under modules/zlib
are copied from modules/zlib/src to modules/zlib/install during build stage. 
So, I think we're fine there.

Comment 12

[Chris Waterson]

> static component loader seems to fail if the patches under xpinstall/stub are
> removed... this is a problem.  I'll need some help to resolve this issue.
> question is should I check in those work around in xpinstall/stub in the mean
> time?

No, let's fix it right the first time. I can do this if need be.

> I also tried changing xpinstall to use libjar approach building xpinstall
> as dll, and it also works too.  Should I use this undefing method or the my
> current META_COMPONENT and modules/statimod changes?  any preference?

Let's do it with the |!undef|, to make it explicit that we're building these as 
DLLs _all_ the time. (Otherwise, somebody might come along later and just think 
we forgot to convert them to the new build-fu.)

Comment 13

[Brendan Eich [:brendan]]

If there are new ? files (? in first column of cvs up output), and those files
are expected and minimal byproducts of the static build, please add them to the
.cvsignore file checked into the same directory.

/be

Comment 14

[Cathleen]

> > static component loader seems to fail if the patches under xpinstall/stub 
> > are removed... this is a problem.  I'll need some help to resolve this 
> > issue. question is should I check in those work around in xpinstall/stub in 
> > the mean time?
>
> No, let's fix it right the first time. I can do this if need be.

I'm going to take up your offer!  :-)  

I already have the changes for xpinstall in my tree.  I'll attach my patch soon,
and adding those .cvsignore files too

Comment 15

[Cathleen]

Attachment: backed out xpinstall/stub changes, backed out modules/staticmod changes, used udef in xpinstall, and added .cvsignore files

Comment 16

[Cathleen]

Attachment: works! :-)

Comment 17

[Chris Waterson]

Groovy. [s]r=waterson.

Comment 18

[Daniel Veditz [:dveditz]]

r=dveditz for attachment 42802 [details] [diff] [review]

Comment 19

[Cathleen]

checked in.  yeah!

Comment 20

[Cathleen]

marking FIXDED