Closed Bug 520394 Opened 14 years ago Closed 14 years ago

Build config changes for Cocoa Printing


(MailNews Core :: Build Config, defect)

Not set


(Not tracked)

Thunderbird 3.1b2


(Reporter: philor, Assigned: philor)




(2 files, 1 obsolete file)

Attached patch Fix (obsolete) — Splinter Review
Lurking behind the bug 516858 trunk Mac failure is another: we try to rsync PrintPDE.plugin, but it's no longer built by default, because the default is now to use the bug 456646 Cocoa print dialog. Since that uses the bug 389074 Core Text check to define ac_cv_have_leopard, it's simpler just to port them both.
Attachment #404442 - Flags: review?(bugzilla)
Comment on attachment 404442 [details] [diff] [review]

Not had time to look at this in detail yet, but:

+if test "$MOZILLA_1_9_1_BRANCH" = "1"; then

do we know if the cocoa printing changes going onto 1.9.2? If not, we should include 1.9.2 in the checks.
A fun question: I assumed so, since bug 456646 is wanted1.9.2+, but with 1.9.2 headed for the door at top speed, maybe it won't make it. Markus?
We decided to create a 1.9.2 version of the Cocoa printing patch that doesn't use any configure flags, always compiles both the Carbon and the Cocoa dialog and makes the decision which one to use at runtime.
Mmm, today's plan, in bug 520494, is even simpler: ifdef MOZILLA_1_9_1 we rsync PrintPDE.plugin, otherwise it's gone, no configure options, no nothing. I can live with being broken on top of mozilla-central (behind other breakage) until that lands.
Depends on: 520494
Summary: Port Core Text and Cocoa Printing changes → Build config changes for Cocoa Printing
Attached patch Fix v.2Splinter Review
Simplicity, it's a good thing.
Attachment #404442 - Attachment is obsolete: true
Attachment #404555 - Flags: review?(bugzilla)
Attachment #404442 - Flags: review?(bugzilla)
Comment on attachment 404555 [details] [diff] [review]
Fix v.2

Thinking about it, I'd also argue whether we actually need the MOZ_COCOA_PRINTING and MOZ_CORETEXT defining for trunk anyway - it would be surprising if we needed a build config ifdef in comm-central that uses them (except I suppose packaging files).

Hmm, no changes? How does the updater service cope with removing the appropriate files/directories?

r+a=Standard8 on the makefile changes as we'll need them anyway.
Attachment #404555 - Flags: review?(bugzilla)
Attachment #404555 - Flags: review+
Attachment #404555 - Flags: approval-thunderbird3+
We're looking good for Fx landing changes, which will be the first use of "../", and adding a path like that to the updater tests, so once that bakes a day or two I'll remove our files (directories don't get removed: the updater doesn't support that, only the Windows installer does).
Actually, we're close enough to branching and the files are harmless enough that I'll just wait instead of adding yet another ifdef.
Whiteboard: [needs branch][needs patch for]
This no longer needs a branch ;-)
Whiteboard: [needs branch][needs patch for] → [needs patch for]
Depends on: 521372
Attached patch removed-filesSplinter Review
Well, I think we'll survive without the test, since Fx has all these months (and I just had to look at the diff to see what this patch I've been carrying in my queue for months actually was).
Attachment #427963 - Flags: review?(bugzilla)
Whiteboard: [needs patch for]
Attachment #427963 - Flags: review?(bugzilla) → review+
Closed: 14 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1b2
(In reply to comment #12)

Are the '$' actually expected in the SM file? (The lines look like truncated...)
Resolution: FIXED → ---
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.