Add a simple autotools buildsystem

[GoogleCodeExporter]

If this is supposed to be a serious project, it should have a build system to 
install the header files and a pkg-config file as requested in another bug.

Original issue reported on code.google.com by mgo...@gentoo.org on 30 Aug 2011 at 4:21

[GoogleCodeExporter]

Here's a patch to add one:
- https://github.com/mgorny/npapi-sdk/commit/9b054832e.diff

It may be also a good idea to move COPYING to the main dir, as the copyright 
applies to NPAPI headers as well:
- https://github.com/mgorny/npapi-sdk/commit/1e369286c01.diff

Original comment by mgo...@gentoo.org on 30 Aug 2011 at 4:45

[GoogleCodeExporter]

Don't jab at us with phrases like "If this is supposed to be a serious project" 
to imply that we're not serious if we don't do what you want. It's not 
appreciated. Just make your argument and we'll make a decision.

Original comment by josh....@gmail.com on 1 Sep 2011 at 4:25

[GoogleCodeExporter]

And FYI, this is the canonical upstream header source for at least the top 
three NPAPI-supporting browsers (in addition to a number of plugins; those tend 
to be closed-source so it's hard to say how many). I'm pretty sure that makes 
us a "serious project" whatever your personal opinion might be.

Original comment by stuart.morgan on 2 Sep 2011 at 9:17

[GoogleCodeExporter]

If this is a canonical header source, it would be nice to have a 
canonical/supported/common way of installing and compiling against the API. 
Providing a buildsystem and pkg-config support would provide a common and easy 
way for package to discover and compile against NPAPI. This would make things 
much cleaner for distros.

Please consider distributing such a buildsystem with NPAPI.

Original comment by ohnobinki on 2 Sep 2011 at 4:43

[GoogleCodeExporter]

Here are my patches which:

1) create a simple autotools install for it (installing headers into 
/usr/include/npapi-sdk),
2) move COPYING into top-level dir (so that it is clear that LICENSE applies to 
all files within),
3) generate NPAPI version consts from configure.ac (it is nicer to have the 
version defined on one place only, and configure.ac needs one const).

The third patch is based on sources with pkg-config file added but can be 
rebased easily to work without it.

Original comment by mgo...@gentoo.org on 4 Sep 2011 at 10:12

Attachments:

• 0001-Add-an-autotools-build-system.patch
• 0002-Move-COPYING-to-the-root-dir.patch
• 0004-Generate-NPVERSION-from-VERSION.patch

[GoogleCodeExporter]

Requiring everyone to run configure would make this much more painful for Mac 
and Windows developers (as compared to just having to check out the source and 
go). I'm all for making this easy to use on Linux, but not at the expense of 
other platforms.

Original comment by stuart.morgan on 5 Sep 2011 at 5:39

[GoogleCodeExporter]

Then please just ignore the last patch here. This will make the package fully 
compatible with autoconf-less run. Windows/Mac users could just grab files from 
the package/svn as they do now, and Linux users could use configure to get the 
pkg-config file as well.

Original comment by mgo...@gentoo.org on 5 Sep 2011 at 6:47

[GoogleCodeExporter]

Well, ignoring the last patch shouldn't be necessary. The tarball generated by 
`make dist' includes a working npapi.h, so packages should be no less usable 
than before on both Windows and Mac OSX as there is no need to run ./configure.

From what I remember, Mac OSX should be able to run the ./configure shipped in 
a dist tarball out of the box. If you happen to have Xcode installed, as most 
people developing on a Mac OSX box would, you also get a working make which 
would allow you to install npapi-sdk to a prefix. Xcode also comes with a 
working `autoreconf -vfi' which works with a checked out repo. (OK, I'm 
confused; how are Mac OSX developers supposed to check out npapi-sdk's repo? 
Oh, apparently Xcode includes SVN so we are already assuming that the Mac OSX 
developer has XCode...)

The guides I've seen for compiling things on Windows point people to using 
precompiled binaries for dependent libraries and such. Using a dist tarball to 
get the npapi.h wouldn't be that different...

Original comment by ohnobinki on 5 Sep 2011 at 2:01

[GoogleCodeExporter]

I wouldn't add any build system here. Even WebKit uses 8(!!!) build systems 
http://trac.webkit.org/wiki/Unifying%20the%20build%20system
I wonder what other build systems might be used in plugins.
These sources can't be used as is in browsers. Each browser has its own copy 
checked in the source control.

Of cource, adding a build system might be harmless, but it might be useless as 
well.

Original comment by Van...@gmail.com on 23 Feb 2012 at 10:28