Closed Bug 482462 Opened 11 years ago Closed 11 years ago

Make shark builds enable DTrace

Categories

(Release Engineering :: General, defect)

x86
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: benjamin, Assigned: benjamin)

References

Details

Attachments

(2 files, 1 obsolete file)

The Shark build should enable dtrace, since they are targeting 10.5-only and it won't hurt... dtrace-enabled builds can be used to produce more interesting profiles.
Attachment #366550 - Flags: review?(nthomas)
Attachment #366550 - Flags: review?(nthomas) → review+
Comment on attachment 366550 [details] [diff] [review]
--enable-dtrace for shark builds, rev. 1

r+. If you land this the builds will pick it up next time they run.
(In reply to comment #0)
> The Shark build should enable dtrace, since they are targeting 10.5-only ...

Does the build system do this automatically for Shark ? We're using the usual 10.4u SDK via the universal build mozconfig include.
(In reply to comment #2)
> (In reply to comment #0)
> > The Shark build should enable dtrace, since they are targeting 10.5-only ...
> 
> Does the build system do this automatically for Shark ? We're using the usual
> 10.4u SDK via the universal build mozconfig include.


bsmedberg/ted: gentle ping?
Enabling dtrace does require the 10.5 SDK. I've posted to the newsgroups about changing this build configuration to require the 10.5 SDK.
Per newsgroup, going to use the 10.5 SDK, not do a universal build, and enable dtrace.
Attachment #366550 - Attachment is obsolete: true
Attachment #378063 - Flags: review?(nthomas)
Attachment #378063 - Attachment is patch: true
Attachment #378063 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 378063 [details] [diff] [review]
--enable-dtrace for shark builds (also disable universal and use the 10.5 sdk), rev. 2

Looks fine to me. 

Do you know about the equivalent production config at mozilla2/macosx/mozilla-central/shark/mozconfig ? Not sure if you want to land both simultaneously (r+ counts for both if so) or do a build in staging to make sure all is well.
Attachment #378063 - Flags: review?(nthomas) → review+
Duplicate of this bug: 500447
http://hg.mozilla.org/build/buildbot-configs/rev/826259445d59
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Shark builds are failing across m-c, m-1.9.1, TraceMonkey, places:
  make buildsymbols
  make: *** No rule to make target `buildsymbols'.  Stop.
Presumably the mozconfig changes have left MOZ_CRASHREPORTER undefined now.

Is it useful to be uploading symbols separate from the shark dmg ? Seems a bit redundant, particularly if we're not uploading to the symbol server.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Not particularly useful, no, but not really harmful. Let me add the --enable-crashreporter back for the time being anyway.
Ah, actually what's happening is: the buildbot is calling `make buildsymbols` in objdir/ppc which doesn't exist any more.
I don't really know how to test this, but I think it does what you want. It should definitely be tested on -staging before going near production.
Attachment #389698 - Flags: review?(nthomas)
Comment on attachment 389698 [details] [diff] [review]
Set the correct objdir for shark builds, rev. 1

Works fine in staging. Landed: 
  http://hg.mozilla.org/build/buildbot-configs/rev/973ab27c970a
Attachment #389698 - Flags: review?(nthomas) → review+
Pushed patch onto the master and reconfig'd. --> FIXED.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.