Not sure if this should go to plugins or build config. The plugin SDK needs to be incorporated into the Mozilla build system so we can generate the headers for each platform. If would also probably be good to build the samples when DISABLE_TESTS is not defined.

Why not to build them each cycle? They do not need to be exported anywhere but making sure we never break it looks attractive to me.

With this patch, you can now build the Mac samples in the tree. This patch probably needs to be expaned to include a build flag and also automatically build the samples, but I think I'll wait until after Conrad's XML project changes at the start of next week.

Done for Windows. Now it is just a matter of triggering it by changing mozilla/modules/plugin/makefile.win: - DIRS= base\public base\src samples\default\windows + DIRS= base\public base\src samples\default\windows tools\sdk What kind of sr do we need for this? Serge, would you please look at Unix makefiles?

I'm on it.

just uncomment #ENABLE_PLUGIN_SDK_SAMPLES = 1 in /mozilla/modules/plugin/Makefile.in and all samples will build in the tree automatically

nominating nsbeta1, mozilla1.0

Marking nsbeta1+. Moving to Mozilla1.0 per ADT triage.

Reassigning to peterl, as on Window and Unix changing building scripts is trivial, so Mac should get most of attention.

With this patch, I can successfully complete both Carbon and Classic Mac builds with the SDK samples built. Please review. I think this is the last step needed to make the SDK part of the build. Are other platforms ready? Should one combined patch be made to land at the same time? Also, not sure if any of the sample code in the SDK has been reviewed. Perhaps a super reviewer could glance over it to give a blessing?

Please use a MANIFEST file instead of all those MakeAlias calls.

I created MANIFEST_PluginSDK files in every module we need headers from. I had a little trouble with XPCOM as I needed some IDL'ed headers that are in dist:xpcom. Please comment/review.

adding adt3 to status whiteboard as per discussion with beppe.

Hmm, now I see why perhaps you didn't use a manifest in the first place; the files you need are scattered throughout the tree, requiring a number of manifest files. However, I still think this solution is better, since folks making changes to the main MANIFEST files are more likely to see your plugin manifests, and maintain them. Having idl-generated headers in the plugin SDK seems somewhat risky to me. Shouldn't you include the idl, and force plugin authors to build the idl themselves?

In order to use the raw IDLs, I think I'd have to include extra projects to build them which is not currently done on other platforms. Maybe it could be cleaner if a Perl script located in the SDK could just be executed to do all the MakeAlias calls? Can that be done with our build system or stand-alone?

You could do that, but then you lose locality, so folks might remove headers that the plugin sdk needs, and omit to fix up the plugin SDK file copying.

Comment on attachment 74797 [details] [diff] [review] patch using MANIFESTs I would really prefer that we use a single script file rather than littering the tree with these additional MANIFEST files. Let's consider moving the script for building the SDK itself out of MozillaBuildList.pm.

Fair enough.

After talking this one over with several folks, this is not needed for the current release, this can wait. Removing ADT3 and marking as nsbeta1-

For those who don't have the ability to generate their own Mozilla builds, MacCarbonSDKd1.sit is from my debug carbon build and contains the headers, converted xml to mcp projects, built xpt type libraries, and built samples.

Here's an zip of my Windows built SDK directory from my debug build.

Here is a sample Mac SDK from the tree built under Classic

I applied the Linux patch, but I am not able to compile because it says that there is no Makefile.in in tools/sdk/common. I am using the 1.0RC2 source tree.

well, linux patch is kind of old and probably it needs some changes.

this needs to be reworked, will account for this in the next round of work

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment on attachment 61824 [details] [diff] [review] linux patch to build sdk samples I've checked in linux part of tools/sdk/samples

The Gecko SDK already contains all the NSPR and XPCOM headers and tools needed by plugin developers but does not contain NPAPI headers. The Gecko SDK is already part of the build and can be found in mozilla/dist/sdk and is packaged nightly for Win32 here: http://ftp.mozilla.org/pub/mozilla/nightly/latest/gecko-sdk-win32.zip This patch adds the needed headers to build NPAPI plugins to the Gecko SDK so plugin developers just need a single SDK to get the right headers, tools, and libs and then can use the sample project files. This patch also enables building the plugin sdk samples on Win32 when ENABLE_TESTS is defined.

Comment on attachment 111005 [details] [diff] [review] patch v.1 r=cls

updated patch now builds tests on Linux and Darwin because it contains the fixes to the SDK from bug 186163 and bug 185776.

Comment on attachment 111581 [details] [diff] [review] patch v.2 r=cls

last patch had some problems when added to the build: can't copy files in export:: that don't exsist Here's a new patch that replaces the header file copy w/ REQUIRES lines

Comment on attachment 112229 [details] [diff] [review] patch v.3 r=cls

seeing approval to land last patch for mozilla 1.3b The risk is low as the plugin samples are only compiled if ENABLE_TESTS is defined.

Comment on attachment 112229 [details] [diff] [review] patch v.3 a=asa (on behalf of drivers) for checkin to 1.3beta. (you want "approval1.3b?" in the attachment not "blocking1.3b?" in the bug to request approval to land.

SDK now builds with ENABLE_TESTS and all needed headers are in the GeckoSDK, marking FIXED