Part of the XULRunner planning is not only to release builds of the XULRunner runtime platform, but also to produce and release a set of developer tools, which for lack of a better name I have been calling the XULRunner SDK, or XDK for short.

Several characteristics distinguish the XULRunner SDK from the currently released Mozilla SDK packages:

• In addition to headers and import libraries for the frozen APIs exposed by the Mozilla platform, the XDK will contain headers for non-frozen interfaces. These headers will be segregated in a way that makes it clear to developers that they are using nonfrozen APIs.
• The XDK will provide tools to aid in the development, debugging, testing, and deployment of applications that use the Mozilla platform. This includes extensions and XULRunner applications, as well as embedding applications. The goal is to make use of existing projects and tools as much as possible. Potential tools that may be included include:
• A build system which can be used to package extensions and XULrunner-based applications from sources
• Deployment tools which can be used to create installers for XULRunner-based applications.
• Debugging tools such as DOM Inspector, a JavaScript debugger, and leak-detection tools.
• Localization tools

I am now in the process of implementing the build system which will be used to produce the XDK. My basic strategy is to package the XDK by tarring up the dist/ directory from a XULRunner build, just as the XULRunner runtime itself is packaged from the dist/bin directory. In order for this strategy to be reasonable, several things need to happen:

• The dist/lib directory structure needs to be cleaned out. That directory should only contain static libs and import libs that will be used by embedders. All of the shared libraries that are currently installed to dist/lib as well as dist/bin will only be installed to dist/bin. All the intermediate static libraries that are currently installed to dist/lib will not be installed and will instead be referenced from their in-tree location.
• The dist/include directory structure needs to be cleaned out. Headers which are only meant for internal use will be removed from the EXPORTS section of makefiles and will either be referenced from their in-tree locations or will be installed to module-specific locations (think /layout/include).
• The dist/bin directory needs to be cleaned out. Currently tests and other files are installed to dist/bin. These tests and other files will be installed to other locations as appropriate.

I would like some feedback on this proposal, especially as it affects RPM packages and Linux distributions. My current idea for RPM structures would look like this:

• XULRunner-1.9 RPM
  ships the contents of dist/bin to /usr/lib/xulrunner-1.9
• XULRunner-dev-1.9 RPM
  depends on XULRunner-1.9
  ships the contents of dist to /usr/lib/xulrunner-1.9-dev
  /usr/lib/xulrunner-1.9-dev/bin is a symlink to /usr/lib/xulrunner-1.9 (to avoid having to ship two copies of the XULRunner runtime)

Yes, I know that this structure is a bit nonstandand and it would be slightly more unix-like to ship the headers to /usr/include/xulrunner-1.9. But I think it’s important to keep the structure, so that the mozilla build system can be used –with-libxul-sdk=/usr/lib/xulrunner-1.9-dev and have everything “just work”.

This entry was posted on 27 Mar, 2006 at 3:55 pm and is tagged with , xulrunner. Trackback.