482462 - Make shark builds enable DTrace

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Benjamin Smedberg]

Attachment: --enable-dtrace for shark builds, rev. 1

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.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

(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.

Comment 3

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(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?

Comment 4

[Benjamin Smedberg]

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.

Comment 5

[Benjamin Smedberg]

Attachment: --enable-dtrace for shark builds (also disable universal and use the 10.5 sdk), rev. 2

Per newsgroup, going to use the 10.5 SDK, not do a universal build, and enable dtrace.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 8

[Benjamin Smedberg]

http://hg.mozilla.org/build/buildbot-configs/rev/826259445d59

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 10

[Benjamin Smedberg]

Not particularly useful, no, but not really harmful. Let me add the --enable-crashreporter back for the time being anyway.

Comment 11

[Benjamin Smedberg]

Ah, actually what's happening is: the buildbot is calling `make buildsymbols` in objdir/ppc which doesn't exist any more.

Comment 12

[Benjamin Smedberg]

Attachment: Set the correct objdir for shark builds, rev. 1

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.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 14

[Nick Thomas [:nthomas] (UTC+12)]

Pushed patch onto the master and reconfig'd. --> FIXED.