This tweaks the hashtable API, and it is incomplete because the WUtil proplist
impl depends heavily on a feature of the old API that is being discontinued.
Moving the proplist code into Rust is our next objective.
This type of PropList entry appears to be completely unused, so let's be rid of
it. This can be reversed in the future if we do want more complete support for
property lists, but for now it's code that we don't need.
All memory allocations passed back from FFI functions should be allocated with
`memory::alloc_bytes`, so that C code can call `memory::free_bytes` when it's
done with them.
While this large change has some unit tests, it has not been integration tested
thoroughly. Removing the global case insensitivity flag may be an issue in
particular.
A few of PropList API functions have been modified (mostly to get rid of
varargs). The definition of one such function has been left in C for cleanup
later.
This symbol's value must be known to port `wmkdirhier` and `wrmdirhier` from
`proplist.c` to Rust.
This change introduces a basic C library under wutil-rs that is linked into the
Rust code to expose preprocessor symbols and other Autotools configuration
decisions to Rust. See the rust rewrite notes at the top of
`wutil-rs/src/defines.rs` for further thoughts.
This is not tested super well, but I hope we can be rid of it soon enough. (Once
we have WMPropList migrated, WMData and other WINGs data structures should be
easier to prune.)
This constructor was only needed in one particular place. We can duplidate the
data instead of borrowing it. This ensures that WMData always owns its data
segment, which simplifies porting to Rust significantly.
This is another utility that should not be used in any new (Rust) code. (We
should prefer Vec or something similar.) This should be removed once dependents
are ported to Rust.
This is not a bug-for-bug reimplementation, and it may need some shaking down to
ensure that everything still works. Once their dependents are ported, it would
be appropriate to dispose of them.
This is necessary because we now allocate memory through a special allocator of
our own on the Rust side. Passing raw malloc'd pointers to wfree will break
things.
This is done to simplify memory management across the boundary between C and
Rust. While rewriting WINGs, we may want to be able to malloc/free with the libc
allocator on both sides of that divide.
Now ./configure checks for cargo and rustc, and `make` will rebuild wmaker-rs if
any of its source code has changed.
There are still some steps to take for better integration (like ensuring that
deps are vendored correctly). See
https://viruta.org/librsvgs-build-infrastructure-autotools-and-rust.html for
suggestions on what else to do.
trurl