Allow optionally compiled code based on the existence of a system library

[svenfoo]

I am trying to change librsvg to use system-deps and I am encountering what looks like a missing feature to me. But perhaps I have just misunderstood the documentation and what I would like to do can already be achieved.

We have optional dependencies on pangoft2 and on some cairo surface backends. Currently build.rs checks these dependencies using pkg-config and creates have_pangoft2, have_pango_pdf etc. cfg switches. Depending on these switches some features are optionally compiled in.

This is the other way around that system_deps handles optional dependencies, right? As far as I understand it, insystem_deps an optional dependency is bound to a feature, so that the dependency is only checked if the feature is enabled. What we would like to have is that system_deps checks for the availability of a system library and enables or disables a feature accordingly. Is that possible?

[gdesmott]

Correct, system-deps currently does not support such feature and work "the other way around" as you described.

Maybe we could add something like this:

pangoft2 = { optional = true }

making probing not fail if the dep is missing, and let client code handle it how they see fit in build.rs by checking if the dep is in the returned hash or not? I'm not sure that's system-deps's job to enable/disable features so it may be best to let users do that?

@sdroege : any advice? :)

[sdroege]

How do you currently enable the feature in build.rs and how do you call it? Maybe system-deps could automatically enable features for such optional dependencies if configured to do so?

pangoft2 = { optional = true, feature-if-found = "have_pangoft2" } ?

[gdesmott]

How do you currently enable the feature in build.rs and how do you call it?

We are currently checking if a feature is enabled by checking if the CARGO_FEATURE_$NAME env variable is present. Not sure if we can use rustc-env to define features using the same pattern?

[svenfoo]

It wouldn't necessarily have to be a feature in the Cargo sense.

In case it helps, here's a link to our current 'build.rs' that is not using system_deps yet: https://gitlab.gnome.org/GNOME/librsvg/-/blob/master/build.rs

[gdesmott]

Oh it's quite easy:

println!("cargo:rustc-cfg=have_pangoft2");

which is then used in code with:

#[cfg(have_pangoft2)]

So I guess system-deps could do something like this:

println!("cargo:rustc-cfg=system_deps_have_$DEPNAME");

I think that should work for your use case, right?

[gdesmott]

@svenfoo : I implemented this in https://github.com/gdesmott/system-deps/pull/30 Can you please give a try and let me know if that fix your use case?

[gdesmott]

I just released 3.0.0 with this new API.

[svenfoo]

Thanks for the quick fix and the release. I have updated my pull request for librsvg accordingly.

[federicomenaquintero]

Thanks for adding this feature! This will make things a lot easier for librsvg.

[gdesmott]

My pleasure. :) system-deps is a quite young project which has been started to fit gtk-rs's needs at first. I'm happy to extend it to cover other use cases.