Use core maths

[LaurenzV]

So what I did here is that I always include the core_maths dependency and I removed no-std-float, so that in order to enable no_std mode, you can simply disable all default features and don't need to additionally enable a separate feature. The reason for this is that since features are additive, it's apparently bad practice to have an explicity no_std feature.. Because if one crate depends on std of ttf-parser and another on no-std-float, then both features would be activated if a crates uses both of them as a dependency.

If you want I can undo the last part, though.

[RazrFalcon]

Yep, looks good to me.

[alexheretic]

This means ttf-parser now depends on core_maths & libm always. Part of the point of having a "libm" feature (or equivalent) is to opt into it when you need it for no-std compilation and to avoid additional dependencies otherwise for the (quite common) "std" case.

Previously ttf-parser had no dependencies.

ttf-parser v0.23.0
└── core_maths v0.1.0
    └── libm v0.2.8

Because if one crate depends on std of ttf-parser and another on no-std-float, then both features would be activated if a crates uses both of them as a dependency.

This is a true, but odd, point. This hasn't been solved here, 0.23 just does the equivalent of this for everyone unconditionally.

What was solved was no-std users don't need to enable a feature at the cost of std users getting extra dependencies.

[LaurenzV]

Yeah, I know, unfortunately there doesn't seem to be a perfect solution for this, it's a trade-off. But as I mentioned above, I don't have a strong opinion on it, for me it's fine to undo the feature part.

[alexheretic]

Yep it's a tradeoff, just seems worth considering for this crate as it is so lean on dependencies.

Having the extra dependencies using "std" doesn't seem to affect the size of binaries afaics. But there is a minor regression in clean compile times.

0.22

~/p/ttf-parser $ hyperfine --runs 6 --prepare 'rm -rf ./target' 'cargo build --target-dir target'
Benchmark 1: cargo build --target-dir target
  Time (mean ± σ):      1.205 s ±  0.009 s    [User: 1.489 s, System: 0.172 s]
  Range (min … max):    1.188 s …  1.213 s    6 runs

master (0.23)

~/p/ttf-parser $ hyperfine --runs 6 --prepare 'rm -rf ./target' 'cargo build --target-dir target'
Benchmark 1: cargo build --target-dir target
  Time (mean ± σ):      1.439 s ±  0.030 s    [User: 1.771 s, System: 0.212 s]
  Range (min … max):    1.411 s …  1.497 s    6 runs

[RazrFalcon]

To my understanding libm will be ignored by the complier during std builds. Yes, we have to compile it, but it's not actually linked/used.

The problem is simple: we need trigonometry functions for no_std builds. To get them we need libm. If libm is optional, then it breaks no_std builds, since we have to explicitly enable it now.

And if you have two crates, one of which depends on std ttf-parser and one depends on no_std ttf-parser - then you will get core_maths/libm anyway.

If you have a better solution I will gladly accept it.

[alexheretic]

I think the previous approach, having a feature, was mildly better.

And if you have two crates, one of which depends on std ttf-parser and one depends on no_std ttf-parser - then you will get core_maths/libm anyway.

Yes but as I said before this is an edge case where the downside is the same downside now applied to everyone.

Using a feature, a crate downstream of ttf-parser can still also support no-std with a "libm" feature and use that to activate ttf-parser's feature. E.g.

[features]
libm = ["dep:libm", "ttf-parser/libm"]

So there isn't a good reason that the dependency tree will inevitably have no-std ttf-parser in it anyway as there is a pattern to activating it when necessary.

I guess the argument for the ergonomics is that no-std users already have to set default-features = false so it isn't much harder to add features = ["libm"].

So imo having the feature is generally the best approach because it minimises dependencies. I've used this approach myself too (e.g. ab_glyph_rasterizer) and I don't think it causes a problem for no-std usage.

But overall, I can live with either way. So I've probably banged on about this enough now! 😅

[RazrFalcon]

Would making core_maths an optional dependency will be a good enough solution? libm requires a bit more work.