search

mooman219 / fontdue

The fastest font renderer in the world, written in pure rust.
Apache License 2.0
1.45k stars 72 forks source link

Hashbrown outdated and usage of std-only f32 features ? #21

Closed MarimeGui closed 4 years ago

MarimeGui commented 4 years ago

Hello to anyone reading this !

I am in the process of building a Console for a bare-metal PowerPC system (can you guess which one ?) with fontdue 0.0.4 !

When creating the console under native Windows/x64, everything worked just fine, I then copied my code over to my main PPC repo, adapted stuff and tried compiling it...

You might have guessed it didn't go far:

error[E0463]: can't find crate for `std`
  --> /home/guillaume/.cargo/registry/src/github.com-1ecc6299db9ec823/hashbrown-0.5.0/src/lib.rs:36:1
   |
36 | extern crate std as alloc;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = note: the `powerpc-none-eabi-2552456384893224483` target may not be installed

Looking at the surrounding code in the repo for hashbrown version 0.5.0, it performs a check for the 'nightly' feature, but fails somehow ?

Anyways, it was apparently fixed in a later release, because trying to cross-compile hashbrown 0.5 on it's own (without fontdue) in a separate crate with minimal code fails just like above, but when raising the version to 0.6 for example the build works just fine.

Cloning fontdue locally and modifying the version to 0.6 fixes the issue with hashbrown, but raises another one: A lot of code in fontdue that uses f32 fns like .powi(), .ceil() or .abs() fails to compile.

I also tried on my native Windows/x64 machine, on a crate WITH std, cloning the repo locally and changing the version of hashbrown to 0.6 raises the same f32 fns issues !

As far as I understand, this bug in hashbrown made the std-only f32 fns available in fontdue's no-std environment, but when upgrading hashbrown, fixing this bug, these features aren't available anymore to fontdue and the build fails, just like one would expect...

So this raises a bit of an issue... Correct me if I am wrong, but the std-only features were used by mistake in developpement of this crate because of that bug ? This is quite the problem for supporting no-std platforms, one of the biggest features of this crate...

Is this really what I think ? I'd be willing to help to fix these issues to get my project back on track !

Thanks, Marime Gui

mooman219 commented 4 years ago

Whoops, my install of rust was a little non-typical and built fine with #![no_std]. I'm not sure why the CI was building fine... but anyway I've switched to 1.43 stable and it's now showing the errors, I'll get a fix out. I'll also update to Hashbrown 0.8.

MarimeGui commented 4 years ago

Thanks ! Looking forward to a fix !

mooman219 commented 4 years ago

WIP, updated hashbrown and removed all but .fract(). I used libm's implementations on floor and ceil because it had a compatible license \o/. I'll update the crate after I fix fract.

mooman219 commented 4 years ago

Done, pushed 0.1.0 because I broke some APIs since 0.0.4. I updated the docs, some functions got extra parameters like offset for subpixel positioning.