Gate find-system-font example behind 'fs' feature

[NoisyCoil]

Hello. cargo test --all --no-default-features fails because the find-system-font example cannot compile unless the fs feature is enabled:

error[E0599]: no method named `load_system_fonts` found for struct `Database` in the current scope
 --> examples/find-system-font.rs:7:8
  |
7 |     db.load_system_fonts();
  |        ^^^^^^^^^^^^^^^^^ method not found in `Database`

error[E0599]: no variant or associated item named `File` found for enum `Source` in the current scope
  --> examples/find-system-font.rs:30:36
   |
30 |             if let fontdb::Source::File(ref path) = &src {
   |                                    ^^^^ variant or associated item not found in `Source`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `fontdb` (example "find-system-font") due to 2 previous errors

This PR gates the example behind said feature, so that non-default tests do not fail. Ref: https://sources.debian.org/src/rust-fontdb/0.21.0-1/debian/patches/fix-tests.patch/

[RazrFalcon]

You shouldn't be using --no-default-features with tests. It would never work. Not for this crate, not most other Rust crates.

[NoisyCoil]

In Debian packaged rust crates are tested first as cargo test --all --no-default-features, then as cargo test --all --no-default-features --features $FEATURE for all single independent features $FEATURE (including default). If some of these tests do not and cannot pass we disable them, while if we can patch them so that they pass feature-wise we do so, and then we often submit the patch upstream. This PR is a case of the latter. Of course if you are not interested you can just ignore it :-)

[dhardy]

You shouldn't be using --no-default-features with tests.

This is an unusual view IMO. Except that this is not merely a test but an example.

@NoisyCoil you could try instead cargo test --tests --lib --no-default-features.

[NoisyCoil]

@dhardy Thank you, but we have standardized testing in Debian. Using --all instead of --tests --lib within the test suite is intentional as it tries to compile (but not run) examples. Thus cargo test --all --no-default-features is precisely what I need to pass. I've already patched the crate in Debian, so this is fixed downstream, but I thought upstream could be interested in the fix, provided that they are interested in making this kind of tests pass in the first place. If not then this PR can be closed.

[RazrFalcon]

Of course if you are not interested you can just ignore it

Again, the problem is that you will not be able to build most Rust libraries this way. All my libraries would fail for sure.
So unless we patch all my libraries then this PR makes not sense.

I don't know if Rust/Cargo requires for tests/examples to compile with --no-default-features.

[NoisyCoil]

Again, the problem is that you will not be able to build most Rust libraries this way. All my libraries would fail for sure.
So unless we patch all my libraries then this PR makes not sense.

Again, you are free to reject this patch, but if you want some limited stats based on what I can see in Debian here they are.

In Debian we do test all of your (and anyone's) libraries as explained above. The libraries of yours I could find using grep -RIi "Source:.*razrfalcon" src/*/debian/copyright in the debcargo-conf repository are:

color-thief, fontdb, memmap2, pico-args, rctree, roxmltree, rustybuzz, simplecss, strict-num, svgdom, svgtypes, tiny-skia, tiny-skia-path, ttf-parser, unicode-bidi-mirroring, unicode-ccc, unicode-vo, xmlparser, xmlwriter

Of these, those whose tests fail due to non-default feature testing are fontdb, roxmltree, tiny-skia-path and ttf-parser. A patch is available only for fontdb (this PR), included downstream. Since tiny-skia-path and ttf-parser require an explicit feature choice between std and no-std-float (and ttf-parser also needs other features to be enabled), this kind of testing does not apply to them, and in fact we do disable failing feature tests. roxmltree is in a similar position given that most (if not all) of the tests are written assuming that the std feature is enabled, so tests fail both with no active features and for the positions feature, and we only run tests for the std and default features.

I don't know if Rust/Cargo requires for tests/examples to compile with --no-default-features.

I don't think so.

[RazrFalcon]

this kind of testing does not apply to them, and in fact we do disable failing feature tests

That's what I was talking about. If the requirement is not mandatory, then it makes sense.

I will accept the patch. I was just confused with the purpose.

Do you need a version bump as well?

[NoisyCoil]

Thank you! No version bump needed, we can pick it up after the next upgrade.