Last Comment Bug 531292 - Port |Bug 530723 - Disable ipc, since it requires libxul and we can't build that way (yet)| to SeaMonkey
: Port |Bug 530723 - Disable ipc, since it requires libxul and we can't build t...
Status: RESOLVED FIXED
:
Product: SeaMonkey
Classification: Client Software
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: seamonkey2.1a1
Assigned To: Serge Gautherie (:sgautherie)
:
Mentors:
Depends on: 523094
Blocks: 394502
  Show dependency treegraph
 
Reported: 2009-11-26 09:24 PST by Serge Gautherie (:sgautherie)
Modified: 2010-01-09 09:23 PST (History)
2 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
(Av1) Just disable both of them [Checkin: Comment 2] (763 bytes, patch)
2009-11-26 09:38 PST, Serge Gautherie (:sgautherie)
standard8: review+
Details | Diff | Review

Description Serge Gautherie (:sgautherie) 2009-11-26 09:24:29 PST

    
Comment 1 Serge Gautherie (:sgautherie) 2009-11-26 09:38:29 PST
Created attachment 414745 [details] [diff] [review]
(Av1) Just disable both of them
[Checkin: Comment 2]
Comment 2 Serge Gautherie (:sgautherie) 2009-11-27 06:41:22 PST
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 (not working on stability any more) 2009-12-14 09:12:12 PST
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) 2009-12-14 09:39:40 PST
(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 (not working on stability any more) 2009-12-14 12:30:25 PST
(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) 2009-12-14 13:05:19 PST
(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 (not working on stability any more) 2009-12-14 13:08:41 PST
(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.

Note You need to log in before you can comment on or make changes to this bug.