774813 - Bug 774139 will break Qt builds due to #define signals

Status: RESOLVED FIXED

(Core Graveyard :: Widget: Qt, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

For example

https://tbpl.mozilla.org/php/getParsedLog.php?id=13596284&tree=Try

In file included from ../../../dist/include/jsproxy.h:12:0,
                 from ../../../dist/include/dombindings.h:12,
                 from ../../../dist/include/nsDOMTouchEvent.h:13,
                 from ../../../dist/include/IPC/nsGUIEventIPC.h:10,
                 from ../../../ipc/ipdl/_ipdlheaders/mozilla/plugins/PPluginInstance.h:21,
                 from ../../../ipc/ipdl/_ipdlheaders/mozilla/plugins/PPluginInstanceChild.h:9,
                 from ../../../dist/include/mozilla/plugins/PluginInstanceChild.h:10,
                 from ../../../dist/include/mozilla/plugins/PluginModuleChild.h:32,
                 from ../../../../dom/plugins/ipc/NestedLoopTimer.cpp:10:
../../../dist/include/jsfriendapi.h:296:16: error: expected unqualified-id before ';' token
../../../dist/include/jsfriendapi.h: In member function 'JS::Value& js::shadow::Object::slotRef(size_t) const':
../../../dist/include/jsfriendapi.h:308:22: error: expected ',' before '-' token
../../../dist/include/jsfriendapi.h:308:22: error: expected identifier before '-' token
../../../dist/include/jsfriendapi.h: In lambda function:
../../../dist/include/jsfriendapi.h:308:31: error: expected '{' before ';' token
../../../dist/include/jsfriendapi.h: In member function 'JS::Value& js::shadow::Object::slotRef(size_t) const':
../../../dist/include/jsfriendapi.h:308:31: error: invalid initialization of non-const reference of type 'JS::Value&' from an rvalue of type 'js::shadow::Object::slotRef(size_t) const::<lambda()>'
make[6]: *** [NestedLoopTimer.o] Error 1

Comment 1

[Ed Morley [:emorley]]

The Qt builds aren't explicitly listed on https://developer.mozilla.org/en/Supported_build_configurations , so it is not clear what tier we should be treating it as.

Qt is currently busted and showing on inbound, so if Qt builds are:
* tier 1, then bug 774139 needs to come out.
* tier 2/3, we need to work out who we should be CC'ing on this bug (I've guessed at romaxa & vladimir, not sure if I've remembered correctly) - and I will hide the builds on TBPL. We will also need to decide how long we leave the builds busted, before just switching them off to save cycles (hopefully it won't come to this).

CCing bsmedberg in the hope he can help answer the tier N question...

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

We don't ship Qt builds and don't plan to, so they're not Tier I.  I couldn't find instructions on building for Qt anywhere on d.m.o or w.m.o, so it's unclear what developers need to do locally to even attempt fixing the builds.  That seems like a pretty basic requirement for not hiding builds on tbpl ...

If the build bustage isn't fixed by the time I wake up tomorrow, I'm going to hide the builds on tbpl.

Comment 3

[Ed Morley [:emorley]]

Given the points made in comment 2 (and my patience for starring the builds on inbound rapidly diminishing) I've hidden them on inbound for now. Easily unhidden once fixed :-)

Comment 4

[(not currently active) Ted Mielczarek]

I believe these were quasi-Tier-1 at one point because we were using the Qt widget backend for our Meego builds. Now that we're no longer shipping those, this is probably not important and could be relegated to Tier-2 status (and not show up on the Firefox tinderbox).

Comment 5

[Ed Morley [:emorley]]

(In reply to Ted Mielczarek [:ted] from comment #4)
> (and not show up on the Firefox tinderbox).

Do you mean run them, but hidden by default, or to stop running the builds altogether? (As Bug 772419 was proposing).

The latest inbound merge has brought the bustage to m-c (and thus profiling), so hidden on those as well.

Comment 6

[(not currently active) Ted Mielczarek]

Stop running them. I've commented in that bug.

Comment 7

[Oleg Romashin (:romaxa)]

Can we just fix the problem, instead of killing Qt builds?

Comment 8

[(not currently active) Ted Mielczarek]

Sure. However, it shouldn't be up to cjones to fix them. If we have the Qt builds running on the Firefox tinderbox, and someone breaks them, it gives the appearance that we ought to back them out, when that really isn't the case.

Comment 9

[Oleg Romashin (:romaxa)]

hmm why not? Qt builds running on tinderbox/try it is just notification that your patch breaking compilation of some existing port. and it is good at least to keep that compiling.
https://bugs.webkit.org/show_bug.cgi?id=62916 - running try builds on patches under review, and that at least keep existing ports in sane state.

Comment 10

[Benjamin Smedberg]

I have posted to mozilla.dev.planning about the build tier/support status of Linux Qt, and I expect to come to a final decision by the end of the week. In the mean time, I believe the current status quo of keeping the Qt builds running but hidden is the correct decision, and Oleg or other interested parties can prepare the patch to fix the Qt builds.

Comment 11

[Oleg Romashin (:romaxa)]

Attachment: Fix for conflict of nasty qt includes defines with js object slots...

Comment 12

[Oleg Romashin (:romaxa)]

https://hg.mozilla.org/mozilla-central/rev/e2a85c456c3e