mozilla-plugin.pc should not depend on mozilla-xpcom.pc

RESOLVED FIXED

Status

RESOLVED FIXED
12 years ago
11 months ago

People

(Reporter: braden, Assigned: braden)

Tracking

({fixed1.8.0.10, fixed1.8.1.2})

Trunk
x86
Linux
fixed1.8.0.10, fixed1.8.1.2

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
Created attachment 250676 [details] [diff] [review]
Patch

mozilla-plugin.pc's dependency on mozilla-xpcom.pc is obsolete. Persons who need to compile plug-ins that need XPCOM can use mozilla-xpcom.pc directly; meanwhile, plug-ins that don't need XPCOM shouldn't be linking with libxpcom.
Attachment #250676 - Flags: superreview?(shaver)
Attachment #250676 - Flags: superreview?(shaver) → review?(benjamin)

Comment 1

12 years ago
Comment on attachment 250676 [details] [diff] [review]
Patch

By the same plugin, why would these plugins require NSPR?

Comment 2

12 years ago
by the same logic, even
(Assignee)

Comment 3

12 years ago
npapi.h includes prtypes.h.
Status: NEW → ASSIGNED

Comment 4

12 years ago
Comment on attachment 250676 [details] [diff] [review]
Patch

That's... unfortunate. Can that be fixed?
Attachment #250676 - Flags: review?(benjamin) → review+
(Assignee)

Comment 5

12 years ago
I think so--as long as we don't care about source compatibility with stuff that compiles against npapi.h today.

Bug 366858.
(Assignee)

Updated

12 years ago
Whiteboard: [checkin needed]

Comment 6

12 years ago
checked in:
mozilla/build/unix/mozilla-plugin.pc.in  1.3
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
(Assignee)

Updated

12 years ago
Attachment #250676 - Flags: approval1.8.1.2?
Attachment #250676 - Flags: approval1.8.0.10?
Why should we be taking this on the branches? What's the impact, risk, gain?
(Assignee)

Comment 8

12 years ago
Risk is negligible, if it exists at all. In the worst case, build systems that were relying on mozilla-plugin.pc to pull in libxpcom build flags will have to be modified to do that a different way (presumably by using mozilla-xpcom.pc explicitly).

The gain is that clients using mozilla-plugin.pc that do *not* use XPCOM will no longer incur a spurious dependency on libxpcom.
Comment on attachment 250676 [details] [diff] [review]
Patch

approved for 1.8/1.8.0 branches, a=dveditz for drivers
Attachment #250676 - Flags: approval1.8.1.2?
Attachment #250676 - Flags: approval1.8.1.2+
Attachment #250676 - Flags: approval1.8.0.10?
Attachment #250676 - Flags: approval1.8.0.10+
(Assignee)

Updated

12 years ago
Whiteboard: [needs checkin]
Whiteboard: [needs checkin] → [checkin needed (1.8 branch)][checkin needed (1.8.0 branch)]

Comment 10

12 years ago
Braden:  We need this landed asap if it's going to make the release, so if you can find someone to land this for you before Monday morning, that'll great!  Maybe bsmedberg?
Whiteboard: [checkin needed (1.8 branch)][checkin needed (1.8.0 branch)] → needs landing on 1.8 and 1.8.0 branches
(Assignee)

Comment 11

12 years ago
This has been checked in on the 1.8 and 1.8.0 branches.
Whiteboard: needs landing on 1.8 and 1.8.0 branches
Keywords: fixed1.8.0.10, fixed1.8.1.2
For the record, this is the type of stuff that should NOT be landing on branches after there has been a release and people are dependent on the behavior.  Several customers have already complained.  The fact that this was not even release noted is just plain sloppy.

Updated

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