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
|