Bug 774139 will break Qt builds due to #define signals

RESOLVED FIXED

Status

Core Graveyard
Widget: Qt
RESOLVED FIXED
5 years ago
11 months ago

People

(Reporter: cjones, Unassigned)

Tracking

Trunk
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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

5 years ago
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...
Depends on: 772419
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

5 years ago
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 :-)
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

5 years ago
(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.
Stop running them. I've commented in that bug.
Can we just fix the problem, instead of killing Qt builds?
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.
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.
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.
Created attachment 643680 [details] [diff] [review]
Fix for conflict of nasty qt includes defines with js object slots...
Attachment #643680 - Flags: review?(jones.chris.g)
Attachment #643680 - Flags: review?(jones.chris.g) → review+
https://hg.mozilla.org/mozilla-central/rev/e2a85c456c3e
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.