Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support building against NPAPI-SDK as well. #117

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants

binki commented Sep 16, 2011

Please pull the patch by mgorny which adds support to lightspark to build against npapi-sdk.

npapi-sdk is a collection of the headers which define the nsplugin interface. As more people use browsers which are not mozilla-based, it is a hindrance to some to need to install a full seamonkey/firefox/xulrunner installation just to get the nsplugin headers. npapi-sdk alleviates the need for this.

The pulled patch will not change the behavior of lightspark's buildsystem for users which do not have npapi-sdk installed. For such users, the old method of compiling directly against xulrunner's nsplugin headers will proceed as normal. This patch adds support for the people who need to compile nsplugins but don't want to install the full xulrunner sdk.

Contributor

janimo commented Sep 16, 2011

We and users spend too much time dealing with NPAPI build failures and I think we'd be better off shipping the handful of headers ourselves. I know it used to be like this and Alessandro changed it at some point.

mgorny commented Sep 16, 2011

This solution deals with NPAPI build failures ultimately. Unlike Mozilla, we know what API is and we aren't going to package or push any API changes into the repo without at least changing version.

Contributor

magcius commented Sep 16, 2011

If anything, we're going to ship the NPAPI headers in-tree. I'm not sure what the benefit of mgorny's fork is. Mozilla has said the recommended way to build is to include the SDK headers in-tree.

binki commented Sep 17, 2011

That sounds like that mozilla folks would say. I think that's part of the reason why npapi-sdk exists -- because Mozilla folks do not always do a good job at supporting compiling against system-installed mozilla APIs.

It is much cleaner to not maintain another copy of the nsplugin API in yet another project. If you do decide to bundle them, might you at least provide an option to compile against the system-installed npapi-sdk for distros to use?

Contributor

magcius commented Sep 17, 2011

That sounds like that mozilla folks would say.

I won't tolerate this. Closed.

@magcius magcius closed this Sep 17, 2011

mgorny commented Sep 17, 2011

Mozilla is not a 'nix project. If they could, they would bundle whole system with their browser. Oh wait, Google already does that. On the other hand, 'nix people have package managers and share codebase. This is what it is about.

Contributor

magcius commented Sep 17, 2011

Mozilla is not a 'nix project. If they could, they would bundle whole system with their browser. Oh wait, Google already does that. On the other hand, 'nix people have package managers and share codebase. This is what it is about.

We will not build against your npapi-sdk fork. If anything, we'll build against the mozilla-plugin.pc and the xulrunner headers that most people use, but probably not, because it's unreliable. It's four header files that can easily be included in-tree without much breakage at all because of the design of NPAPI. Doing your own thing without guidance or support from Mozilla is not something I personally will accept.

However, if Mozilla adapts your npapi-sdk changes to include an autotools build system (for four header files? why?) and the .pc file, and distributions start packaging it, we'll use it.

Also, accusing Mozilla of being the champion of evil and doing everything wrong when all you've done is insult them is not going to help your case.

mgorny commented Sep 17, 2011

Mozilla isn't interested in doing releases. Someone has to do the hard job.

Do you have any technical arguments? I'm not really into this fanboy stuff.

Contributor

janimo commented Sep 19, 2011

mgorny, thanks for bringing up the issue, it reminded us how annoying building against NPAPI can be. For now we carry the 4 header files in LS source and no longer depend on an external package. Hopefully when distros agree to provide a package named uniformly we could depend on that small package.
And I agree that the work you are doing is needed in order to get the files comply with packaging norms in various distros - pc files for example.

cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment