Closed Bug 783740 Opened 8 years ago Closed 7 years ago

SpiderMonkey builds should be using clang on OS X

Categories

(Release Engineering :: General, defect, P3)

x86_64
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: philor, Unassigned)

References

Details

(Whiteboard: [spidermonkey])

What with the whole thing where building on Mac gcc is only supported (in a sort of vague way, since it's currently broken) until August 27th, probably should start in on switching them over now.
Whiteboard: [spidermonkey]
The script that builds these is here, looks like there's already a Mac-specific block in the mozconfig setup:
https://github.com/mozilla/build-tools/blob/master/scripts/spidermonkey_builds/spidermonkey.sh#L65
It should be easy to export CC and CXX similar to what is done for linux:

        export CC=/tools/gcc-4.5/bin/gcc
        export CXX=/tools/gcc-4.5/bin/g++

but we have to make sure tooltool is running on those builds. Is it possible to test these builds on try? If not, how do I test a change locally?
Chatting with philor on IRC it looks like we really can use tooltool for this:

<philor> espindola: http://mxr.mozilla.org/build/source/buildbotcustom/misc.py#2205 (and ScriptFactory) is pretty much all the buildbot parts, beyond that you're in spidermonkey.sh

<philor> espindola: so, probably some work for tooltool, since it's implemented in MozillaBuildFactory and ScriptFactory is just a plain BuildFactory

Should someone from releng be assigned to this?
So, these builds are busted now:

https://tbpl.mozilla.org/?tree=Mozilla-Inbound&noignore=1

Anyone?  Bueller?  Bueller?
Depends on: 789357
dmandelin, tbpl Spidermonkey builds are being shut off. (See bug 785798 (Win) and bug 789357 (Mac))

The issue on Windows seems to be bug 778469 and the issue on Mac is this one.

Are we sure we want them off tbpl?
Wrong question. The right question to ask is "Can we somehow persuasively argue that in the future they would be a good use of resources, even though they historically have not been?"
The problem really is they're not on tbpl.  They're on the noignore tbpl, which is not the default view, which (particularly with the push-and-forget inbound model) nobody actually checks.  Fix that, and people will care more.

I fixed a bunch of the Windows warning, perhaps all of it, early last week or so, I don't remember when.  Perhaps I should investigate whether I fixed all of them, then post a backout of bug 785798's patch to revert the stop-buildness on Windows...

And yes, I do find it useful to have a JS engine that builds without warnings.  And I am willing to spend resources -- my own when necessary -- to ensure it.  The premise of comment 6 is wrong in my book.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #7)
> The problem really is they're not on tbpl.  They're on the noignore tbpl

Yeah and that's because:
1) To unhide, we would need spidermonkey builds on Try as well as all other trunk repos; which will mean extra infra load. Someone needs to convince releng this would be a good use of capacity (though given they only run on js/src/ changes, hopefully the impact of other trees won't be too great) and file the necessary bugs.
2) More importantly, the JS team has repeatedly taken a "oh we shouldn't have to back out over warnings as errors, we just want to know about them and fix a few days/weeks later" approach. This isn't compatible with having the builds visible on TBPL, since we cannot have unstarred bustage for hours/days/weeks on end.

If the JS team changes position on #2, gets the capacity ok from releng & files the bugs to switch on for all trees - then the sheriffs will unhide them as they are fixed up.

Until then, having multiple builds (https://bugzil.la/778460,778467,778469) busted for months on end is just being selfish with machine time.
#2 is asinine, but I haven't won the argument yet.  (But neither have I lost it.)

I can't speak to the root-analysis builds or their value, as that's still a very experimental configuration really of interest only to people working on the GC; but if they don't care, I don't see why anyone else should.

The no-methodjit bit I will shed no tears over, as I think -- to optimize resources, even -- it'd be best to drop no-methodjit support entirely.  But it's not an argument I'll go out of my way to make.

The loss of the completely-normal Windows build configuration (or Mac, or any else) I consider unacceptable.  I don't really want to be on the hook to keep it working all the time, or to nag offenders to fix regressions promptly.  But if that's what it takes to have a generally warning-free build, I will do it.  (Note that Windows broke shortly after I went on vacation in mid-July and was turned off before I returned.  I don't think that's a coincidence.)
Don't get me wrong - I'm not against warnings-as-errors in general, since I think our current situation of several thousand warnings when building Firefox is just ridiculous, since some do hide real bugs. (Though I admit the variation in compiler versions used by devs does make it a hard problem to solve without pushback, given that people don't use try). If the position on #2 can be changed, then great :-)

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #9)
> (Note that Windows broke shortly after I went on
> vacation in mid-July and was turned off before I returned.  I don't think
> that's a coincidence.)

Ah, fair point. However, it does seem both unfair & unsustainable to just have one person being responsible for/caring about the warnings-as-errors builds. But I guess I'm preaching to the converted...
cc'ing Steve, because he's done a lot of work on the Spidermonkey scripts.
Yeah, when they currently fail as they fail every single time, the command that fails is "/usr/bin/clang++ ..."
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.