On Thu, Oct 23, 2008 at 12:48 PM, Sam Gross <[EMAIL PROTECTED]> wrote:
> I think even if we stripped out the unecessary header and idl files, the > libraries to compile OOPHM on the major platforms would be at least 200 Mb. > Since few people will want to rebuild the plugin - and almost everyone has > Firefox installed - it doesn't seem worthwhile to put full Gecko SDKs in the > tools directory. > One problem is 32/64 issues -- for example, on my Ubuntu 8 desktop, it has only the 64-bit FF3 install, so I have no way of building a 32-bit plugin there with this scheme. My CentOS4 machine at home has both 32 (/usr/lib/firefox) and 64-bit (/usr/lib64/firefox) versions installed, so it is buildable, but it is a bit awkward in the way the Makefile currently works. We can leave it this way for now, but probably need to look at how much we can trim it down to -- perhaps just the few individual libraries would be sufficient and we can rely on the installed version for headers/idl files. > Only the regular Firefox distribution. The file gecko-sdks.tar.gz > (attached to the previous email) contains the required headers and libraries > that aren't included in the regular Firefox distribution. We will probably > want to commit these files to tools/ at some point. > Do you have the steps you took to generate them from an install? Is it just a full build of FF and pick out the library/xpidl? If we are going to use a system-supplied FF, does it make sense to rely on a xulrunner-devel package that includes libxpcomglue_s.a and xpidl? In particular I need to be able to get the files for Windows. I also have to figure out how to run xpidl as part of the Windows build process, though it might be better to have the outputs checked in for 1.8 and 1.9, and use the right one. I rearranged things a bit to account for 64-bit machines and different architectures -- instead of just linux/libxpcomglue_s.a it is now Linux_x86-gcc3/libxpcomglue_s.a etc. It wouldn't be ideal, but I don't think it would be the end of the world to >> have two different XPIs, each of which list the versions they are compatible >> with. >> > > That's probably best for the merge with trunk. > I have changed it to produce oophm-xpcom-ff2/oophm-xpcom-ff3 and it is working on FF2 and FF3. It dies on FF1.5 because JS_SetContextCallback was added after FF1.5, though otherwise the API we use seems to be unchanged. In the current code, is the context callback even needed? It looks like ExternalWrapper's destructor gets called before the the context is destroyed, and therefore FFSessionHandler::disconnect does its real work from there and not when contextCallback gets called. I can successfully run in both 1.5 and 2.0 after removing the ContextCallback hooks (haven't tested 3.0 yet, but I don't expect a problem). I'll clean it up a bit more, get Windows FF2/3 working with this setup, and then send it for review. -- John A. Tamplin Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
