22
edits
Toolkit:Platform Specific Extension Components: Difference between revisions
Toolkit:Platform Specific Extension Components (view source)
Revision as of 09:10, 21 May 2005
, 21 May 2005reorganized article
(→Bugs) |
(reorganized article) |
||
| Line 1: | Line 1: | ||
== Introduction == | |||
Some extensions are only intended for one platform, either because it uses things other platforms don't have (e.g. the Windows registry, like Linky does), or because they have binary components. Both the extension manager and services like http://addons.mozilla.org/ would benefit if extensions had some sort of [https://bugzilla.mozilla.org/show_bug.cgi?id=255619 platform-compatibility information as part of their metadata]. Note that themes are handled like extensions in some places, so they could include use such platform-compatibility information, too. | |||
However, solving this issue is not enough, as two problems remain: | |||
== Problem 1 == | == Problem 1 == | ||
A growing number of Firefox and Thunderbird extensions use compiled, binary components. Currently, all these are stuffed into the components/ directory. If you put binaries for several platforms into this components/ directory, you encounter the problem that Win32 loads not only .dll files, but also tries to load linux .so ones and fails with an error message. | A growing number of Firefox and Thunderbird extensions use compiled, binary components. To keep the cross-platform nature Extensions usually have, you have to provide these binaries for each supported platform. Currently, all these are stuffed into the components/ directory. If you put binaries for several platforms into this components/ directory, you encounter the problem that Win32 loads not only .dll files, but also tries to load linux .so ones and fails with an error message. | ||
The effect is that most extensions either | The effect is that most extensions either | ||
| Line 9: | Line 15: | ||
Needless to say, both alternatives aren't very appealing for extension authors. | Needless to say, both alternatives aren't very appealing for extension authors. | ||
Another problem is that binary components have to | Another problem is that binary components have to use the same [http://en.wikipedia.org/wiki/Application_binary_interface ABI] as the host application, or they won't work. Currently, there is no way to check or enforce this - when you install a linux-gcc2-built extension into a linux-gcc3-built application, things just break. | ||
== Problem 2 == | == Problem 2 == | ||
Some themes currently need a separate Macintosh version. While platform compatibility info as part of the metadata would make it impossible for a user to accidently install the wrong package, it would certainly be nice to be able to have one multi-platform theme package that includes some generic "base" files and some platform-specific ones. | |||
Some themes currently need a separate Macintosh version. While | |||
== Conclusions == | == Conclusions == | ||
| Line 23: | Line 25: | ||
We need... | We need... | ||
# components that are only loaded if they were compiled for the same platform AND using the same compiler (gcc/mingw/msvc) as the host application (Firefox, Thunderbird) | # components that are only loaded if they were compiled for the same platform AND using the same compiler (gcc/mingw/msvc) as the host application (Firefox, Thunderbird) | ||
# platform-specific theme jar files, default preferences, window icons and whatever ("this fileset for windows, that one for mac") | # platform-specific theme jar files, default preferences, window icons and whatever ("this fileset for windows, that one for mac") | ||
| Line 38: | Line 39: | ||
: The build environment used to compile the application: gcc2, gcc3, mingw, msvc. | : The build environment used to compile the application: gcc2, gcc3, mingw, msvc. | ||
In each of these directories, the regular directory structure of the package (chrome, components, defaults) is repeated. | In each of these directories, the regular directory structure of the package (chrome, components, defaults for extensions, or the package dirs for themes) is repeated as needed. | ||
The Extension Manager will install the package as usual - i.e. it extracts all files in the archive. The toolkit's nsXREDirProvider is enhanced so it automatically considers not only the extension's base directory, but also the matching platform directories. | The Extension Manager will install the package as usual - i.e. it extracts all files in the archive. The toolkit's nsXREDirProvider is enhanced so it automatically considers not only the extension's base directory, but also the matching platform directories. | ||
| Line 51: | Line 52: | ||
Older Firefox releases would also ignore everything in platform/. | Older Firefox releases would also ignore everything in platform/. | ||
== Example Extension Structure == | == Example Extension Structure == | ||
| Line 88: | Line 87: | ||
* https://bugzilla.mozilla.org/show_bug.cgi?id=253742<br>No way of installing platform specific XPCOM components (dll/so) based on user OS. | * https://bugzilla.mozilla.org/show_bug.cgi?id=253742<br>No way of installing platform specific XPCOM components (dll/so) based on user OS. | ||
* https://bugzilla.mozilla.org/show_bug.cgi?id=294835<br>Need way of determining ABI in makefiles | |||
* https://bugzilla.mozilla.org/show_bug.cgi?id=294835<br>Need | |||