dom/bindings/docs/index.rst@b8a032363ba2 (annotated)
dom/bindings/docs/index.rst
Thu, 22 Jan 2015 13:21:57 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Thu, 22 Jan 2015 13:21:57 +0100
- branch
- TOR_BUG_9701
- changeset 15
- b8a032363ba2
- permissions
- -rw-r--r--
Incorporate requested changes from Mozilla in review:
https://bugzilla.mozilla.org/show_bug.cgi?id=1123480#c6
| michael@0 | 1 | .. _webidl: |
| michael@0 | 2 | |
| michael@0 | 3 | ====== |
| michael@0 | 4 | WebIDL |
| michael@0 | 5 | ====== |
| michael@0 | 6 | |
| michael@0 | 7 | WebIDL describes interfaces web browsers are supposed to implement. |
| michael@0 | 8 | |
| michael@0 | 9 | The interaction between WebIDL and the build system is somewhat complex. |
| michael@0 | 10 | This document will attempt to explain how it all works. |
| michael@0 | 11 | |
| michael@0 | 12 | Overview |
| michael@0 | 13 | ======== |
| michael@0 | 14 | |
| michael@0 | 15 | ``.webidl`` files throughout the tree define interfaces the browser |
| michael@0 | 16 | implements. Since Gecko/Firefox is implemented in C++, there is a |
| michael@0 | 17 | mechanism to convert these interfaces and associated metadata to |
| michael@0 | 18 | C++ code. That's where the build system comes into play. |
| michael@0 | 19 | |
| michael@0 | 20 | All the code for interacting with ``.webidl`` files lives under |
| michael@0 | 21 | ``dom/bindings``. There is code in the build system to deal with |
| michael@0 | 22 | WebIDLs explicitly. |
| michael@0 | 23 | |
| michael@0 | 24 | WebIDL source file flavors |
| michael@0 | 25 | ========================== |
| michael@0 | 26 | |
| michael@0 | 27 | Not all ``.webidl`` files are created equal! There are several flavors, |
| michael@0 | 28 | each represented by a separate symbol from :ref:`mozbuild_symbols`. |
| michael@0 | 29 | |
| michael@0 | 30 | WEBIDL_FILES |
| michael@0 | 31 | Refers to regular/static ``.webidl`` files. Most WebIDL interfaces |
| michael@0 | 32 | are defined this way. |
| michael@0 | 33 | |
| michael@0 | 34 | GENERATED_EVENTS_WEBIDL_FILES |
| michael@0 | 35 | In addition to generating a binding, these ``.webidl`` files also |
| michael@0 | 36 | generate a source file implementing the event object in C++ |
| michael@0 | 37 | |
| michael@0 | 38 | PREPROCESSED_WEBIDL_FILES |
| michael@0 | 39 | The ``.webidl`` files are generated by preprocessing an input file. |
| michael@0 | 40 | They otherwise behave like *WEBIDL_FILES*. |
| michael@0 | 41 | |
| michael@0 | 42 | TEST_WEBIDL_FILES |
| michael@0 | 43 | Like *WEBIDL_FILES* but the interfaces are for testing only and |
| michael@0 | 44 | aren't shipped with the browser. |
| michael@0 | 45 | |
| michael@0 | 46 | PREPROCESSED_TEST_WEBIDL_FILES |
| michael@0 | 47 | Like *TEST_WEBIDL_FILES* except the ``.webidl`` is obtained via |
| michael@0 | 48 | preprocessing, much like *PREPROCESSED_WEBIDL_FILES*. |
| michael@0 | 49 | |
| michael@0 | 50 | GENERATED_WEBIDL_FILES |
| michael@0 | 51 | The ``.webidl`` for these is obtained through an *external* |
| michael@0 | 52 | mechanism. Typically there are custom build rules for producing these |
| michael@0 | 53 | files. |
| michael@0 | 54 | |
| michael@0 | 55 | Producing C++ code |
| michael@0 | 56 | ================== |
| michael@0 | 57 | |
| michael@0 | 58 | The most complicated part about WebIDLs is the process by which |
| michael@0 | 59 | ``.webidl`` files are converted into C++. |
| michael@0 | 60 | |
| michael@0 | 61 | This process is handled by code in the :py:mod:`mozwebidlcodegen` |
| michael@0 | 62 | package. :py:class:`mozwebidlcodegen.WebIDLCodegenManager` is |
| michael@0 | 63 | specifically where you want to look for how code generation is |
| michael@0 | 64 | performed. This includes complex dependency management. |
| michael@0 | 65 | |
| michael@0 | 66 | Requirements |
| michael@0 | 67 | ============ |
| michael@0 | 68 | |
| michael@0 | 69 | This section aims to document the build and developer workflow requirements |
| michael@0 | 70 | for WebIDL. |
| michael@0 | 71 | |
| michael@0 | 72 | Parser unit tests |
| michael@0 | 73 | There are parser tests provided by ``dom/bindings/parser/runtests.py`` |
| michael@0 | 74 | that should run as part of ``make check``. There must be a mechanism |
| michael@0 | 75 | to run the tests in *human* mode so they output friendly error |
| michael@0 | 76 | messages. |
| michael@0 | 77 | |
| michael@0 | 78 | The current mechanism for this is ``mach webidl-parser-test``. |
| michael@0 | 79 | |
| michael@0 | 80 | Mochitests |
| michael@0 | 81 | There are various mochitests under ``dom/bindings/test``. They should |
| michael@0 | 82 | be runnable through the standard mechanisms. |
| michael@0 | 83 | |
| michael@0 | 84 | Working with test interfaces |
| michael@0 | 85 | ``TestExampleGenBinding.cpp`` calls into methods from the |
| michael@0 | 86 | ``TestExampleInterface`` and ``TestExampleProxyInterface`` interfaces. |
| michael@0 | 87 | These interfaces need to be generated as part of the build. These |
| michael@0 | 88 | interfaces should not be exported or packaged. |
| michael@0 | 89 | |
| michael@0 | 90 | There is a ``compiletests`` make target in ``dom/bindings`` that |
| michael@0 | 91 | isn't part of the build that facilitates turnkey code generation |
| michael@0 | 92 | and test file compilation. |
| michael@0 | 93 | |
| michael@0 | 94 | Minimal rebuilds |
| michael@0 | 95 | Reprocessing every output for every change is expensive. So we don't |
| michael@0 | 96 | inconvenience people changing ``.webidl`` files, the build system |
| michael@0 | 97 | should only perform a minimal rebuild when sources change. |
| michael@0 | 98 | |
| michael@0 | 99 | This logic is mostly all handled in |
| michael@0 | 100 | :py:class:`mozwebidlcodegen.WebIDLCodegenManager`. The unit tests for |
| michael@0 | 101 | that Python code should adequately test typical rebuild scenarios. |
| michael@0 | 102 | |
| michael@0 | 103 | Bug 940469 tracks making the existing implementation better. |
| michael@0 | 104 | |
| michael@0 | 105 | Explicit method for performing codegen |
| michael@0 | 106 | There needs to be an explicit method for invoking code generation. |
| michael@0 | 107 | It needs to cover regular and test files. |
| michael@0 | 108 | |
| michael@0 | 109 | This is implemented via ``make export`` in ``dom/bindings``. |
| michael@0 | 110 | |
| michael@0 | 111 | No-op binding generation should be fast |
| michael@0 | 112 | So developers touching ``.webidl`` files are not inconvenienced, |
| michael@0 | 113 | no-op binding generation should be fast. Watch out for the build system |
| michael@0 | 114 | processing large dependency files it doesn't need in order to perform |
| michael@0 | 115 | code generation. |
| michael@0 | 116 | |
| michael@0 | 117 | Ability to generate example files |
| michael@0 | 118 | *Any* interface can have example ``.h``/``.cpp`` files generated. |
| michael@0 | 119 | There must be a mechanism to facilitate this. |
| michael@0 | 120 | |
| michael@0 | 121 | This is currently facilitated through ``mach webidl-example``. e.g. |
| michael@0 | 122 | ``mach webidl-example HTMLStyleElement``. |
