Last Comment Bug 366113 - mozilla-plugin.pc should not depend on mozilla-xpcom.pc
: mozilla-plugin.pc should not depend on mozilla-xpcom.pc
: fixed1.8.0.10, fixed1.8.1.2
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86 Linux
-- normal (vote)
: ---
Assigned To: Braden
: Gregory Szorc [:gps] (away until 2017-03-20)
Depends on:
  Show dependency treegraph
Reported: 2007-01-05 22:12 PST by Braden
Modified: 2007-03-12 11:05 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (580 bytes, patch)
2007-01-05 22:12 PST, Braden
benjamin: review+
dveditz: approval1.8.1.2+
dveditz: approval1.8.0.10+
Details | Diff | Splinter Review

Description User image Braden 2007-01-05 22:12:02 PST
Created attachment 250676 [details] [diff] [review]

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.
Comment 1 User image Benjamin Smedberg [:bsmedberg] 2007-01-11 16:04:22 PST
Comment on attachment 250676 [details] [diff] [review]

By the same plugin, why would these plugins require NSPR?
Comment 2 User image Benjamin Smedberg [:bsmedberg] 2007-01-11 16:04:46 PST
by the same logic, even
Comment 3 User image Braden 2007-01-11 16:35:00 PST
npapi.h includes prtypes.h.
Comment 4 User image Benjamin Smedberg [:bsmedberg] 2007-01-12 10:40:57 PST
Comment on attachment 250676 [details] [diff] [review]

That's... unfortunate. Can that be fixed?
Comment 5 User image Braden 2007-01-12 13:33:12 PST
I think so--as long as we don't care about source compatibility with stuff that compiles against npapi.h today.

Bug 366858.
Comment 6 User image Nickolay_Ponomarev 2007-01-25 03:41:06 PST
checked in:
mozilla/build/unix/  1.3
Comment 7 User image Daniel Veditz [:dveditz] 2007-01-29 11:06:05 PST
Why should we be taking this on the branches? What's the impact, risk, gain?
Comment 8 User image Braden 2007-01-29 11:48:27 PST
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 9 User image Daniel Veditz [:dveditz] 2007-01-30 15:32:36 PST
Comment on attachment 250676 [details] [diff] [review]

approved for 1.8/1.8.0 branches, a=dveditz for drivers
Comment 10 User image Jay Patel [:jay] 2007-02-02 14:13:03 PST
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?
Comment 11 User image Braden 2007-02-04 13:41:39 PST
This has been checked in on the 1.8 and 1.8.0 branches.
Comment 12 User image Christopher Aillon (sabbatical, not receiving bugmail) 2007-03-12 11:05:26 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.