93100 - fix meta-component fu so that gecko can be built as a DLL

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[Chris Waterson]

Filing this bug based on ken's plea in bug 92127, ``Currently, the static build 
process requires mailnews. Can we make the process compatible with the 
DISABLE_MAILNEWS setting?''

This may be terribly easy: i.e., simply conditionally excluding the mail meta
module in mozilla/modules/staticmod if the DISABLE_MAILNEWS variable is set.

Comment 1

[Daniel (Leaf) Nunes]

except that the installer is expecting mailnews, so we need to use even yet 
another manifest file for creating packages (i'm not sure if we have to use 
another set of .jst files in xpinstall, or if the .xpi files are created solely 
from the directories that the manifest creates).

Comment 2

[Chris Waterson]

Who cares about the installer? This is for people that are building the mozilla
tree in order to embed it.

Comment 3

[Daniel (Leaf) Nunes]

maybe the *installer* you don't care about, but embedders still probably want a 
functional list of stuff to embed. Are all the embedding clients keeping their 
own list of what they pull out of dist?

Comment 4

[Cathleen]

accepting, for 0.9.4

Comment 5

[Cathleen]

Attachment: simple fix, just like waterson suggested

Comment 6

[Cathleen]

just finished my build, and it appears to fix it.

Comment 7

[Cathleen]

Attachment: enable making gecko.dll, and honor DISABLE_MAILNEWS flag

Comment 8

[Chris Waterson]

(r|sr)=waterson, pick one. Just to double-check, did you generate a new class ID
for NS_METAMODULE_CID in nsMetaModule_gecko.cpp.in?

Comment 9

[Ken]

minor enhancment request....when MOZ_GECKO_DLL is set, mozilla.exe should link 
to gecko.dll rather than statically linking the same libraries.

That will make isolating bugs much easier by having a testbed (mozilla.exe) 
loading the same gecko.dll as an embedded client.

Comment 10

[Cathleen]

Attachment: implement ken's suggestion (not really tested yet)

Comment 11

[Cathleen]

Attachment: working patch to build gecko.dll (trunk)

Comment 12

[Chris Waterson]

cathleen, FYI, on MOZILLA_0_9_2_BRANCH, the substitutions in 
nsMetaModule_gecko.cpp.in should be surrounded by @...@ characters, not %...%? 
I.e., @DECLARE_COMPONENT_LIST@ instead of %DECLARE_COMPONENT_LIST%. (Looks like 
cls changed this at some point.)

Comment 13

[Ken]

Surrounding those tags with "%" looks correct. taking a look at the cvs log of 
nsMetaModule_crypto.cpp.in, for example...

----------------------------
revision 1.3
date: 2001/07/25 07:01:02;  author: cls%seawood.org;  state: Exp;  lines: +3 -3
Use %var% instead of @var@ as placeholders for the static build dynamic module 
lists.  This prevents acoutput-fast.pl fr
om complaining about unknown variables.
----------------------------

Comment 14

[Cathleen]

I got a new pull of 0_9_2 branch, and will be doing a new build and hand
modify/apply changes.

I landed this fix to trunk last night already.  I'll post a newer patch for the
branch soon after I test it's building correctly.

Comment 15

[Chris Waterson]

Cathleen, don't land this patch on the branch. It turns out that to get this 
stuff working properly, I had to re-write most of the meta-module stuff and 
we'll likely just conflict.

I'm attaching a patch against MOZILLA_0_9_2_BRANCH that will get Ken going on 
win32 with MOZ_GECKO_DLL (but almost everything else broken). I'll then clean 
up the patch so we can land it on the trunk and stuff.

Comment 16

[Chris Waterson]

Attachment: patch, to be applied from immediately above mozilla/

Comment 17

[Chris Waterson]

So it turns out that the old meta-component stuff was registering stuff twice 
(not really harmful in any way, but silly), and it wasn't calling the sub-
module [c|d]tors. I've fixed that, but in the process, had to change 
NS_NewGenericModule()'s signature _again_.

This time, it takes a struct (with version field, even!) nsModuleInfo. The meta-
module simply collects these structs together, and uses them to get at the sub-
module's components, ctor, and dtor.

The above patch will break the current static build until I fix xpfe/bootstrap. 
I also need to port it to Unix. smfr+thesteve, you'll probably need to tweak 
your ju-ju, too.

Comment 18

[Chris Waterson]

Attachment: same as above, with working meta.mak

Comment 19

[Chris Waterson]

Oops. Chundered meta.mak. The last patch should work with MOZ_GECKO_DLL=1.

Comment 20

[Chris Waterson]

taking for now.

Comment 21

[Chris Waterson]

Attachment: with ``normal'' static build working on Win32

Comment 22

[Chris Waterson]

Attachment: fix linux and dynamic build

Comment 23

[Chris Waterson]

The above patch fixes the dynamic build, and updates Linux to work as well. Note
that you'll need the patch in bug 94831 to build static on Linux now. I'll move
this to the trunk, and verify on Mac on Monday.

Comment 24

[Daniel (Leaf) Nunes]

sr=leaf windows build system changes, r=leaf unix build system changes.

Comment 25

[Chris Waterson]

Need to make the same changes on Mac.

Comment 26

[Chris Waterson]

Attachment: unified patch that includes mods for dependent bugs

Comment 27

[Chris Waterson]

Attachment 45749 [details] [diff] includes intl/locale cleanup that's required for bug 93566 and 
bug 94831; this is taken against the MOZILLA_0_9_2_BRANCH.

Comment 28

[cls]

I like the versioning of nsModuleInfo.  Can we mandate that for everything? :)

Just one nit, for *.in substitutions, use %var% instead of @var@.  The latter
causes acoutput-fast.pl (and therefore configure) to complain about @var@ being
unknown and people start filing bugs.  
You didn't include nsMetaModule.cpp.in.  Assuming that file's kosher + the above
tweak, r=cls on attachment 45749 [details] [diff] [review] .

Comment 29

[Ken]

This part of config\rules.mak breaks my static builds under win2k using cygwin 
tools (where the build attempts to output the final-link-libs, etc. files):

!if "$(WINOS)" == "WIN95"
_NO_FLOCK=-l
!else
_NO_FLOCK=
!endif

I have to add '-l' to the else condition. Why is this here? Can it be modified 
to build on win2k?

Comment 30

[Chris Waterson]

cls: thanks. the mods in attachment 45749 [details] [diff] [review] and attachment 45494 [details] [diff] [review] are against
MOZILLA_0_9_2_BRANCH, which is why I'm using the bad old @...@ variables. I've
just finished merging the patch to the trunk, and I'll post one with %...%
variables RSN.

runyonkj: amen, brother! I have the same problem; apparently it's a bad version
of perl, but I've given up and hack my rules.mak every time I pull a new tree.

Comment 31

[Chris Waterson]

Attachment: up-to-date diffs for the trunk

Comment 32

[Chris Waterson]

I've checked these changes in on the trunk.

Comment 33

[Chris Waterson]

Attachment: up-to-date diffs for MOZILLA_0_9_2_BRANCH

Comment 34

[Marek Z. Jeziorek]

let's get it on the branch. thanks

Comment 35

[Chris Waterson]

Fixed on the branch.