`#![no-std]` implementation

[LGFae]

These crates seem sufficiently simple to warrant a #![no-std] implementation. This would allow them to be used in binaries that do not link std. People may do that mostly on memory-constrained environments, such as embedded devices. Another reason to do that is simply trying to generate smaller binaries in general.

In any case, I believe it would make the crates more flexible, for very little cost.

For fontconfig-sys literally all it takes is changing the imports from std::os::raw to core::ffi. That's the recommended import anyway, in fact. For fontconfig, it is almost just changing the imports. The only problem is a PathBuf usage that will have to become a String in #[no_std] environments.

I have already implemented all these changes, and can open a PR if the maintainers of this repository are willing to maintain this. I believe it would be very easy. In fact, the diff is very small:

➜ g d --stat
  fontconfig-sys/src/lib.rs |  6 ++++--
  fontconfig/Cargo.toml     |  2 ++
  fontconfig/src/lib.rs     | 46 ++++++++++++++++++++++++++++++++--------------
  3 files changed, 38 insertions(+), 16 deletions(-)

---

EDIT: actually, upon more careful examination, fontconfig-sys depends on dlib which automatically generates stuff which imports std::mem::transmute;. So this is currently impossible.

[wezm]

Even if this crate is built no_std is it possible to use the Fontconfig C library that it depends on in such an environment? Fontconfig appears to require an allocator, and file system at a minimum, not sure what else.

[LGFae]

As far as I understand it, I believe you would still need link to link libc precisely for those reasons, and that should give you everything you need.

[wezm]

If you want to open a PR, I'm happy to review it.

changing the imports from std::os::raw to core::ffi. That's the recommended import anyway, in fact.

Either way you're right that this is the recommended import now, so we may as well make that change at least.

[LGFae]

The #![no_std] implementation is currently conditioned to the dlib accepting my no_std PR.

Actually, the implementation without std would still work and compile on its own, but when linking a binary rustc will complain because dlib currently needs std (that's what happened to me).

Either way you're right that this is the recommended import now, so we may as well make that change at least.

I can separate just the stuff that will be useful regardless. One moment.

[wezm]

Since I don't think fontconfig makes sense in a no_std env and #51 was merged, I'm going to close this.