531292 - Port |Bug 530723 - Disable ipc, since it requires libxul and we can't build that way (yet)| to SeaMonkey

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Comment 1

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Just disable both of them [Checkin: Comment 2]

Comment 2

[Serge Gautherie (:sgautherie)]

Comment on attachment 414745 [details] [diff] [review]
(Av1) Just disable both of them
[Checkin: Comment 2]


http://hg.mozilla.org/comm-central/rev/862045be3f26

Comment 3

[Robert Kaiser]

Shouldn't that be MOZ_IPC instead of MOZ_ENABLE_IPC? Also, what does that actually break? I guess very much that all efforts to create a SeaMonkey 2.1a1 are futile without having IPC in there, is there a bug for that?

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #3)

> Shouldn't that be MOZ_IPC instead of MOZ_ENABLE_IPC?

See:
http://hg.mozilla.org/comm-central/rev/7d15f87ed87f
Mark Banner - Build bustage fix following electrolysis landing - MOZ_ENABLE_IPC should actually be MOZ_IPC.
+
http://hg.mozilla.org/mozilla-central/rev/848a7cf64d03
Mark Banner - Comm-central bustage follow electrolysis landing: allow MOZ_IPC to be disabled by default in confvars.sh. r=bsmedberg a=bsmedberg

> Also, what does that actually break?

No idea (= don't care yet): the point here is only to continue to build.

(Does it actually break anything yet? Apart from future _OutOfProcess_ Plugins feature?)

> I guess very much that all efforts to create a SeaMonkey 2.1a1
> are futile without having IPC in there, is there a bug for that?

I don't think so, but you can file one yet if you want.
Bug 394502 has to be fixed first anyway.!.

Comment 5

[Robert Kaiser]

(In reply to comment #4)
> (In reply to comment #3)
> > Also, what does that actually break?
> 
> No idea (= don't care yet): the point here is only to continue to build.

The priority, right, but IMHO not the long-term solution ;-)

> (Does it actually break anything yet? Apart from future _OutOfProcess_ Plugins
> feature?)

OK, from what bsmedberg told me, it shouldn't break anything right now - just the *not future any more* OOPP feature, which is one of the really big and important features of the current 1.9.3 tree, and something we really want to have before the next release, if possible.

Once the feature itself has somewhat stabilized on trunk, we should work with Benjamin to find a solution for us, he seemed sympathetic to that on IRC, with a request to let today's merge settle first. I guess we'll need a new bug for that.

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> The priority, right, but IMHO not the long-term solution ;-)

Yes, this bug is of the "until we can do something about it" kind.

> OK, from what bsmedberg told me, it shouldn't break anything right now - just
> the *not future any more* OOPP feature,

Well, that feature is still 50% future until it gets activated by default.

> I guess we'll need a new bug for that.

Sure, if there is/will a quicker way than/before the libxul one, fine with me.
(Fwiw, what I really wish is to see work resumed toward libxul, as it will "solve" not this problem only...)

Comment 7

[Robert Kaiser]

(In reply to comment #6)
> (Fwiw, what I really wish is to see work resumed toward libxul, as it will
> "solve" not this problem only...)

Fully agreed on that, but the current discussion of roadmap changes (ask me about it on IRC) doesn't favor this happening before a release that can use OOPP.