Platform Specific Projects ========================== .. index:: Platform Specific Projects When a project involves platform-specific code, some consideration needs to be made to the LID file and registry, as well as the layout of code. As an example, consider the `io `_ and `system `_ libraries. In summary, there must be a LID file for each version of your library that needs some platform-specific code, and a platform-specific registry file that points to the appropriate LID file. LID File -------- For further details of the LID file format, see :doc:`../library-reference/lid`. 1) The ``Library`` keyword The library keyword remains the same across all platforms since it is, after all, a platform-dependent version of that library: =============== ========================= ========================= Keyword unix-io.lid win32-io.lid =============== ========================= ========================= Library: io io =============== ========================= ========================= 2) The ``Files`` keyword Each platform's project may contain files that are the same in each platform, as well as files which are present in one but not in another: =============== ========================= ========================= Keyword unix-io.lid win32-io.lid =============== ========================= ========================= Files: buffered-format buffered-format .. format-condition format-condition .. unix-interface win32-interface .. unix-file-accessor win32-file-accessor .. unix-standard-io win32-standard-io .. format-out format-out .. *(etc)* *(etc)* C-Source-Files: unix-portability.c RC-Files: .. version.rc =============== ========================= ========================= 3) The ``C-Libraries`` keyword Each platform's project will probably require a different set of linked libraries. (Here we use an example from the "system" library as the "io" library doesn't link directly against any C libraries.) =============== ========================= ========================= Keyword x86_64-linux-system.lid x86-win32-system.lid =============== ========================= ========================= C-Libraries: -ldl advapi32.lib .. .. shell32.lib =============== ========================= ========================= 4) The ``Platforms`` keyword Platform-specific LID files should use the ``Platforms`` keyword to indicate which platforms they apply to. This helps the `deft update `_ command decide which registry files to create. If there is no ``Platforms`` keyword ``deft`` assumes the LID file applies to the current platform and creates a registry file for its library. =============== ========================= ========================= Keyword unix-io.lid win32-io.lid =============== ========================= ========================= Platforms: x86_64-linux win32 .. x86_64-darwin .. .. x86_64-freebsd .. =============== ========================= ========================= LID File Inheritance -------------------- When LID files are almost identical, it can be useful to create a base LID file and inherit it, overriding whatever is necessary for each platform. A per-platform LID file might look like:: Library: uv LID: uv-posix.lid C-libraries: -framework CoreServices Registry -------- For further details of setting up the registry entries, see :doc:`source-registries`. Normally, when a reference to a platform-independent project is placed in the registry, it is put into the "generic" directory. Platform dependent projects are placed in subdirectories named for the platform. For example, :file:`opendylan/sources/registry/x86_64-linux/io` points to ``unix-io.lid`` and :file:`opendylan/sources/registry/x86-win32/io` points to ``win32-io.lid``. Code Layout ----------- The "io" library is laid out in the following manner: 1. All platform-specific code is inside a single module (io-internals). 2. ``*-interface.dylan`` contains the low-level functions accessing the platform-specific libraries (*e.g.* ``unix-read``, ``win32-read``). 3. ``*-file-accessor.dylan`` uses the functions from (2) to produce a platform-independent API (*e.g.* ``accessor-read-into!``). 4. Only those methods from (3) are exported from the module. .. note:: Most libraries that are portable aren't as complex in their layout as the ``io`` library and don't require separate modules.