Provides the correct C representations for the data structures.
For now it has a lot of code dupplication with apple.rs. These need
to be abstracted and shared keeping only PlatformSupport implementations
and C struct reprs.
enabling openbsd build via mod.rs
not enabling default route on loopback interfaces.
we check the gw address and if it is a loopback one we
don't add the ifindex in the default_route ones.
Here was the error.
```
❯ cargo clippy
Checking veilid-tools v0.2.5 (~/Developer/veilid/veilid-tools)
error: this `MutexGuard` is held across an `await` point
--> veilid-tools/src/tests/common/test_host_interface.rs:269:17
|
269 | let mut tick = tick_1.lock();
| ^^^^^^^^
|
= help: consider using an async-aware `Mutex` type or ensuring the `MutexGuard` is dropped before calling await
note: these are all the `await` points this lock is held through
--> veilid-tools/src/tests/common/test_host_interface.rs:271:25
|
271 | sleep(1000).await;
| ^^^^^
...
274 | sleep(1000).await;
| ^^^^^
...
277 | sleep(1000).await;
| ^^^^^
...
280 | sleep(1000).await;
| ^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#await_holding_lock
note: the lint level is defined here
--> veilid-tools/src/lib.rs:23:9
|
23 | #![deny(clippy::all)]
| ^^^^^^^^^^^
= note: `#[deny(clippy::await_holding_lock)]` implied by `#[deny(clippy::all)]`
error: could not compile `veilid-tools` (lib) due to previous error
```
Targets have been parallelized so that initial push of the container cache should build the whole build a little quicker, plus the container should now use the cache for more of the build and so speed up normal builds to just the compilation and test of the code that has changed
The `build_cache` target now builds a `build-cache:latest` container that is stored in the GitLab project Container Registry, and then used (if it exists) by the `test_build` target. The `build_cache` task runs under 3 conditions, 1. the container does not exist, 2. if scheduled, 3. if run manually from the Pipelines page in the GitLab interface.
It is recommended that the build is set up to run on a weekly schedule via the `Pipeline schedules` page in GitLab with the schedule of `0 2 * * 6`.
