Differences From
Artifact [7cef1da779]:
53 53 libk uses the concept of "atoms" (small, regular strings of text) to standardize common references, such as operating systems or processor architectures.
54 54
55 55 #### operating systems
56 56
57 57 these atoms will be used to reference operating systems.
58 58
59 59 * Linux: `lin`
60 - * Haiku: `haiku`
61 - * Android: `android`
60 + * Haiku: `hai`
61 + * Android: `and`
62 62 * FreeBSD: `fbsd`
63 63 * NetBSD: `nbsd`
64 64 * OpenBSD: `obsd`
65 - * Darwin/Mac OS X: `dar`
65 + * Darwin/Mac OS X/iOS: `dar`
66 66 * MS-DOS: `dos`
67 67 * FreeDOS: `fdos`
68 68 * Windows: `win`
69 69
70 70 #### file extensions
71 71
72 72 * C function implementations: `*.c`
................................................................................
92 92
93 93 ## repository structure
94 94
95 95 libk uses a strict directory structure for code, and deviations from this structure will not be tolerated without extremely good reason.
96 96
97 97 all libk code is dispersed into modules: `kcore` for internals, `kio` for I/O, `kgraft` for binary packing, etc. each module has a folder in the root directory. (libk does not have submodules.) inside each module's directory should be a header with the same name as the module (see **naming conventions** above).
98 98
99 -each function should be kept in a separate file within its module's directory. when OS or architecture-specific code is needed, the file's name should be a list of one or more of the fields [arch, OS, bits, format] separated by a `.` -- for instance, the 32-bit x86 haiku version of a function called `write` defined in assembly would be named `write.x86.haiku.32.s`. however, if a function has an extraordinarily large number of versions, they may instead be stored in a folder with the same name as the function.
99 +each function should be kept in a separate file within its module's directory. when OS or architecture-specific code is needed, the file's name should be a list of one or more of the fields [arch, OS, bits, format] separated by a `.` -- for instance, the 32-bit x86 haiku version of a function called `write` defined in assembly would be named `write.x86.hai.32.s`. however, if a function has an extraordinarily large number of versions, they may instead be stored in a folder with the same name as the function.
100 100
101 101 each module should have a header named the same thing as the module except without the `k` prefix. (e.g. the header for `kio` is `kio/io.h`) located in its folder. this is the header that the end-user will be importing, and should handle any user-defined flags to present the API the user has selected.
102 102
103 103 each module directory should contain a makefile that can build that module. see **makefiles** below. all makefiles should be named `makefile` (**not** `Makefile`).
104 104
105 105 each module should contain a markdown file. this file's name should be the name of the parent directory suffixed with `.md`; for instance, `kterm` should contain the file `kterm/kterm.md`. this file should document the module as thoroughly as possible
106 106