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, found in
For further details of the LID file format, see LID file.
The library 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
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 win-file-accessor unix-standard-io win32-standard-io format-out format-out (etc) (etc) C-Source-Files: unix-portability.c RC-Files: version.rc
Linked Libraries (from dylan-lang/opendylan/sources/system)
Each platform’s project will probably require a different set of linked libraries:
Keyword x86_64-linux-system.lid x86-win32-system.lid C-Libraries: -ldl advapi32.lib shell32.lib
An example from the
systemlibrary was used as the
iolibrary doesn’t link directly against any C libraries.
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
For further details of setting up the registry entries, see Using 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 the platform-labelled subdirectories. e.g.
io library is laid out in the following manner:
- All platform-specific code is inside a single module (
*-interface.dylancontains the low-level functions accessing the platform-specific libraries (e.g.
*-file-accessor.dylanuses the functions from (2) to produce a platform-independent API (e.g.
- Only those methods from (3) are exported from the module.
Most libraries that are portable aren’t as complex in
their layout as the
io library and don’t require separate