Closed Bug 87004 Opened 19 years ago Closed 19 years ago

make xpinstall build separate in STATIC build

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla0.9.3

People

(Reporter: cathleennscp, Assigned: cathleennscp)

References

Details

Attachments

(6 files)

 
Blocks: 81371
Blocks: 46775
OS: Windows 2000 → All
Hardware: PC → All
now need to test it to make sure it actually works!  :-)
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.3
thanks to dveditz's help on resolving the last glitch in libjar.  :-)
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...
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
> * 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.
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
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.
> 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.)
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
> > 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





Attached patch works! :-)Splinter Review
Groovy. [s]r=waterson.
r=dveditz for attachment 42802 [details] [diff] [review]
Summary: make xpinstall build seperate in STATIC build → make xpinstall build separate in STATIC build
checked in.  yeah!
marking FIXDED
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.