chore: updated readme
ci/woodpecker/pr/woodpecker Pipeline was successful
Details
ci/woodpecker/pr/woodpecker Pipeline was successful
Details
parent
ef625ed14e
commit
2cc974accc
36
README.md
36
README.md
|
@ -1,15 +1,12 @@
|
|||
# libvieter
|
||||
|
||||
This library powers part of Vieter, most noteably the sections that can easily
|
||||
This library powers part of Vieter, most notably the sections that can easily
|
||||
be implemented in C (or just parts I want to implement in C because it's fun).
|
||||
|
||||
The goal of this library is to be completely self-contained, meaning any
|
||||
required data structures have to be implemented as well. It can only depend on
|
||||
the C standard libraries.
|
||||
The goal of this library is to be as self-contained as possible; data
|
||||
structures should be implemented manually if possible.
|
||||
|
||||
Currently it contains the following:
|
||||
|
||||
* Cron expression parser & next time calculator
|
||||
See the [source code](/src) for the list of modules.
|
||||
|
||||
## Development
|
||||
|
||||
|
@ -18,6 +15,27 @@ Currently it contains the following:
|
|||
Everything is handled by the provided Makefile. To compile the static library,
|
||||
simply run `make`.
|
||||
|
||||
### Project structure
|
||||
|
||||
Each module has its own subdirectory inside `src`, e.g. `src/cron`. This
|
||||
directory contains the actual implementation of a module, along with any
|
||||
internally used header files. Each internal function should be defined in a
|
||||
header file, as to make testing these possible.
|
||||
|
||||
Each module should also have its own header file inside the `include`
|
||||
directory. This header file defines the public API that the library exposes for
|
||||
this specific module.
|
||||
|
||||
Any code in a module may only import internal headers from that module, along
|
||||
with any of the public API header files. Modules should not depend on each
|
||||
other's internal implementationns.
|
||||
|
||||
Each module should contain a README describing its contents.
|
||||
|
||||
All file names, function names... (even internals) should follow snake case
|
||||
convention and have a prefix unique to that module, starting with `vieter_`.
|
||||
For example, the `cron` modules uses the `vieter_cron_` prefix for everything.
|
||||
|
||||
### Testing
|
||||
|
||||
This library uses [Acutest](https://github.com/mity/acutest) for its tests.
|
||||
|
@ -25,6 +43,10 @@ Tests should be placed in the `test` subdirectory, further divided into
|
|||
directories that correspond those in `src`. Test files should begin with
|
||||
`test_`, and their format should follow the expected format for Acutest.
|
||||
|
||||
Each `test_` is compiled separately into a binary, linked with libvieter. A
|
||||
test file can import any of the public API header files, along with any header
|
||||
files defined in its respective module. This allows testing internal functions.
|
||||
|
||||
To run the tests, simply run `make test`. If you wish to only run a specific
|
||||
test binary, you can find them in `build/test`.
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ vieter_heap_node *vieter_heap_node_init();
|
|||
|
||||
void vieter_heap_node_free(vieter_heap_node *node);
|
||||
|
||||
vieter_heap_node *vieter_heap_node_merge_same_order(vieter_heap_node *root_a, vieter_heap_node *root_b);
|
||||
vieter_heap_node *vieter_heap_tree_merge_same_order(vieter_heap_node *root_a, vieter_heap_node *root_b);
|
||||
|
||||
typedef struct vieter_heap_tree {
|
||||
uint64_t order;
|
||||
|
|
Loading…
Reference in New Issue