Overview
| Comment: | more fixes |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
93014cedbc13d68983eddff866c7bafe |
| User & Date: | lexi on 2019-06-27 12:21:24 |
| Other Links: | manifest | tags |
Context
|
2019-06-27
| ||
| 21:39 | development milestone check-in: a14ceee056 user: lexi tags: trunk | |
| 12:21 | more fixes check-in: 93014cedbc user: lexi tags: trunk | |
| 12:18 | fix typo check-in: 56e588d048 user: lexi tags: trunk | |
Changes
Modified libk.md from [7cef1da779] to [d834bc0082].
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
..
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
libk uses the concept of "atoms" (small, regular strings of text) to standardize common references, such as operating systems or processor architectures. #### operating systems these atoms will be used to reference operating systems. * Linux: `lin` * Haiku: `haiku` * Android: `android` * FreeBSD: `fbsd` * NetBSD: `nbsd` * OpenBSD: `obsd` * Darwin/Mac OS X: `dar` * MS-DOS: `dos` * FreeDOS: `fdos` * Windows: `win` #### file extensions * C function implementations: `*.c` ................................................................................ ## repository structure libk uses a strict directory structure for code, and deviations from this structure will not be tolerated without extremely good reason. 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). 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. 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. each module directory should contain a makefile that can build that module. see **makefiles** below. all makefiles should be named `makefile` (**not** `Makefile`). 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 |
|
|
|
|
|
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
..
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
libk uses the concept of "atoms" (small, regular strings of text) to standardize common references, such as operating systems or processor architectures. #### operating systems these atoms will be used to reference operating systems. * Linux: `lin` * Haiku: `hai` * Android: `and` * FreeBSD: `fbsd` * NetBSD: `nbsd` * OpenBSD: `obsd` * Darwin/Mac OS X/iOS: `dar` * MS-DOS: `dos` * FreeDOS: `fdos` * Windows: `win` #### file extensions * C function implementations: `*.c` ................................................................................ ## repository structure libk uses a strict directory structure for code, and deviations from this structure will not be tolerated without extremely good reason. 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). 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. 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. each module directory should contain a makefile that can build that module. see **makefiles** below. all makefiles should be named `makefile` (**not** `Makefile`). 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 |