| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Don't need these programs any more, so the build recipes for them don't
really make sense to keep.
Also remove the `clean` target since it only relates to `includer` and
`moder`.
|
|
* Release targets for 'dome_key_event_source_simulator'
* Add `release` target
|
|
MadScientist (https://stackoverflow.com/users/939557/madscientist) on
Stack Overflow says:
> Also you should always use := not = for shell (and wildcard, for that
> matter) for performance reasons.
(https://stackoverflow.com/questions/26694249/makefiles-using-wildcard-vs-find-for-specifying-source-files/26694693#26694693)
|
|
The `make build` target requires the `target/debug/deps` directory to
exists so it can copy the media key simulator library into it.
|
|
Turn this into a build dependency with Make.
Use Vladimir Matveev (https://stackoverflow.com/users/788207/vladimir-matveev)
and Shepmaster's
(https://stackoverflow.com/users/155423/shepmaster) answer on Stack
Overflow to sort out getting Cargo the search path for the static
library:
https://stackoverflow.com/questions/26246849/how-to-i-tell-rust-where-to-look-for-a-static-library/26254062#26254062
For some reason I wasn't able to get it to work by just putting the
library into `./target/debug/deps/`. I had to explicitly tell Cargo to
put that in the search path.
Also, we need to use `std::env` instead of the `env!` macro to get the
`PROFILE` environment variable, otherwise it won't be initialised at the
right time, as described in the Rust docs:
> Because these variables are not yet set when the build script is
> compiled, the above example using env! won't work and instead you'll
> need to retrieve the values when the build script is run
(https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts)
|
|
Can't get this working. Tried a bunch of things. Decided to commit this
at a stopping point before messing any further. Sort of getting there,
with some things that seem like they're pointing in the right direction,
but it's not working out so far. Still getting a segfault. Actually,
with the `Box::into_raw` addition, the lifetime of the mode result
actually lasts for a single call (printf), and then gets freed
(weirdly).
Makefile:
* Add `-W` error flags to see if those would give me any extra
information about the pointer problems, but didn't get anything. The
fact that I didn't get errors indicated it was a problem on the Rust
side.
* Change `clean` dependency to `moder.c` so we don't rebuild if the C
file (and lib) hasn't changed.
c_run_key_action():
* Add some `println!`s and debug clutter
* Add a separate `let` binding for `run_key_action_for_mode()` because
that seemed to fix some weirdness in control flow when I was debugging
the code at one point in `lldb`. Not sure it this change still makes
sense to keep.
* Changed function/closure version of `in_mode` to `if`/`else` because
that may have made a difference in some dumb things I was
experimenting with at some point.
* Unsuccessful tries of `mem::forget()`, ultimately commented out.
* Return a `Box::into_raw` pointer to the `CKeyActionResult` instead of
the Rust pointer we were previously returning. This allows the value
to live beyond the function and beyond Rust's control into the calling
C code. This does, however, mean that the value leaks memory, and will
need to be freed manually in the calling C code.
run_key_action_for_mode():
* Wrap map handler in a check to verify `in_mode` is `None`. This
ensures that if we should be returning a `KeyActionResult` for a
mapping inside a mode, we don't run this code that's meant for
mappings outside a mode.
|
|
Add a new `moder.c` based on `includer.c` to test getting a mode and
then getting an action for a mode mapping.
Doesn't completely work currently. Right now all I get is this output:
$ ./moder
2
Segmentation fault: 11
Clearly I'm messing up something with the pointer in
`c_run_key_action()`. Not sure what it is yet.
Changed `CKeyActionResult.in_mode` to be a `Trigger` instead of a
`HeadphoneButton` list. That allows us to pass it directly into the
second argument of `c_run_key_action()` without converting.
But maybe the pointer value isn't living long enough? Not sure what the
problem is yet.
|
|
A new Make target to build the Rust library. This facilitates handling
of other targets that depend on the library.
|
|
|
|
Make a test `includer.c` program that includes the Rust library and
calls our `c_run_key_action()` to see if it actually works. Currently it
doesn't, we get `(null)` printed to stdout.
Add a Makefile with the build command for the C program.
cbindgen.toml:
Remove `KeyActionResult` from exported types, as the `Option` field it
contains caused `gcc` to complain.
cocoa_bridge.rs:
* Comment out all 'cocoa' crate related code as the 'cocoa' code was
interfering with GCC compilation as a result of my not linking to
Cocoa frameworks.
* Add a new test map definition that corresponds with the one we look
for in `includer.c`.
parser.rs:
Add `#[repr(C)]` to `MapKind` because it needs to be exported in the
library and generated into our C header file.
|
