397277 - Make /suite build with --enable-libxul

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Mark Banner (:standard8)]

Attachment: The fix

I've been playing around with building SeaMonkey with --enable-libxul, just to find out what else is required for this to happen (bug 394502) apart from the obvious mailnews conversion.

Some of the problems were in /suite where although we already compile with the external API, we don't compile with libxul. I checked what FF did, and there's some simple conversions required.

Patch attached with those conversions, this will allow /suite to build with --enable-libxul (or without it). I'll comment on bug 394502 in a while with the current instructions to allow a basic SeaMonkey build (only partially working of course) with libxul.

Comment 1

[[e-mail]]

Comment on attachment 282032 [details] [diff] [review]
The fix

Why doesn't do_QueryElementAt work with libxul?

I think one of those enumerators could be changed to a singleton enumerator.

Comment 2

[Mark Banner (:standard8)]

(In reply to comment #1)
> (From update of attachment 282032 [details] [diff] [review])
> Why doesn't do_QueryElementAt work with libxul?

Good question, I've just looked at mxr again, and do_QueryElementAt does seem to be defined in the xpcom glue: http://mxr.mozilla.org/seamonkey/source/xpcom/glue/nsArrayUtils.h#68

I was linking it in/with http://mxr.mozilla.org/seamonkey/source/suite/build/Makefile.in

and I was getting an error along the lines of "vtable undefined for nsQueryElementAt" (I can confirm this later if necessary).

I then (probably incorrectly) assumed that as some of the /browser code appeared to have been changed that the do_QueryElementAt wasn't available externally with --enable-libxul.

So it seems like we should be able to use it, but I don't know why the vtable isn't linking correctly.

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

We use it from libxul...

Comment 4

[Mark Banner (:standard8)]

Attachment: Move some of suite/profile from nsISupportsArray to nsI{Mutable,}Array (checked in)

From various discussions on irc, I need to talk to Benjamin about either implementing something like nsArrayUtils.h/.cpp for nsICollection in glue, or whether dropping nsISupportsArray from RDF (and everywhere else) is the better(?) option.

However, some instances of nsISupportsArray in /suite can be moved to nsI{Mutable,}Array without issue, so this patch does that.

Comment 5

[Mark Banner (:standard8)]

To drop the do_QueryElementAt usage relating to nsISupportsArray for the bookmark code there are two options:

1) don't use RDF for the bookmark code
2) change RDF to use nsIArray rather than nsISupportsArray.

Either way, I'm not going to get to this in the near future and its not high priority, therefore reassign to default owner in case anyone else wants to pick this up.

Comment 6

[[e-mail]]

Attachment: Copy parts of nsSupportsARra [Dupe of next patch]

Comment 7

[[e-mail]]

Attachment: Copy parts of nsSupportsArray.cpp [Checkin: Comment 8+10]

We were missing three symbols; I changed uses of NS_NewISupportsArray to do_CreateInstance and copied the code for NS_NewArrayEnumerator and do_QueryElementAt (unfortunately across repos so there's no history).

Comment 8

[[e-mail]]

Pushed changeset 325c0ff70623 to comm-central.

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #8)
> Pushed changeset 325c0ff70623 to comm-central.

It looks like the new file is missing from the checkin !?

Comment 10

[[e-mail]]

(In reply to comment #9)
> (In reply to comment #8)
> > Pushed changeset 325c0ff70623 to comm-central.
> It looks like the new file is missing from the checkin !?
Pushed changeset 00d766fa4563 to comm-central.

One day I'll get this right first time...