Toolkit:Platform Specific Extension Components: Difference between revisions

Jump to navigation Jump to search

Toolkit:Platform Specific Extension Components (view source)

Revision as of 21:40, 19 May 2005

2,836 bytes added ,  19 May 2005
expanded
(problems, conclusions)
 
(expanded)
Line 1: Line 1:
== Problem 1 ==
== Problem 1 ==


A growing number of Firefox and Thunderbird extensions use compiled, binary components. Previously, all these were stuffed into the components/ directory. Some problems then tried to load components that are not intended for their platform (e.g. Win32 loads not only .dll files, but also linux .so ones) and failed with an error message. The current situation is that most extensions either
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.
# are available in separate Win32 and Linux XPIs, posing problems for updating and http://addons.mozilla.org/  
 
# include all platform binaries and employ hacks to work around the problem
The effect is that most extensions either
Both alternatives aren't very inviting for extension authors.
# are available in separate XPIs for each platform, posing problems for updating and http://addons.mozilla.org/  
# include all platform binaries in one package and employ hacks to work around the problem
 
Needless to say, both alternatives aren't very appealing for extension authors.
 
Another problem is that binary components have to be built with the same compiler 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 ==
Line 17: Line 22:


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)
# a platform-level distinction for packages (e.g. windows only, only windows/mac)
# a platform-level distinction for packages (e.g. windows only, only windows/mac)
# 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")
# components that are only loaded if they match the platform AND the compiler (gcc/mingw/msvc)


== The Solution ==
== The Solution ==


coming soon.
The notion of "platform file sets" is added by introducing a new subdirectory inside extension and theme packages: the '''platform''' directory. For each set of files that somehow depend on the target environment, it contains a directory named in one of the following ways:
(''explain great plan for world domination here'')
 
* [OS_TARGET]
* [OS_TARGET]_[COMPILER]
 
'''OS_TARGET'''
: The platform the host application was compiled for, e.g. WINNT, Linux, Darwin (meaning Mac OS X)...
'''COMPILER'''
: 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.
 
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.
 
A Firefox version built with MSVC for Windows would therefore try to load components and default preferences from directories listed below (if existing), and totally ignore any other subdirectories of platform/.
* components/
* defaults/preferences/
* platform/WINNT/components/
* platform/WINNT/defaults/preferences/
* platform/WINNT_msvc/components/
* platform/WINNT_msvc/defaults/preferences/
 
Older Firefox releases would also ignore everything in platform/.
 
''add install.rdf OS_TARGET stuff somewhere''
 
== Example Extension Structure ==
myExt.xpi:
    install.rdf
    chrome/:
      myExt.jar
    defaults/:
      preferences/:
          myExt.js
    platform/:
      Linux_gcc2/:
          components/:
            mycomponent.so
      Linux_gcc3/:
          components/:
            mycomponent.so
      WINNT/:
          defaults/:
            preferences/:
                myExt-win.js
      WINNT_msvc/:
          components/:
            mycomponent.dll
      WINNT_mingw/:
          components/:
            mycomponent.dll
 
== Open Issues ==
 
* What happens when we put chrome jar files in the platform directories - do they have to be listed in the main chrome.manifest? What if the current platform doesn't have that file, is it just ignored?
* What happens to preference files - can name collisions occur, in which sequence are they loaded, are prefs overwritten if specified in both the base prefs file and a platform-specific one?


== Bugs ==
== Bugs ==


https://bugzilla.mozilla.org/show_bug.cgi?id=253742 - 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=255619<br>Ability to restrict to compatible operating systems
Jens.b
22

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/7124"

Navigation menu