gdesmott/system-deps

Run pkg-config from declarative dependencies in Cargo.toml

system-deps

system-deps lets you write system dependencies in Cargo.toml metadata, rather than programmatically in build.rs. This makes those dependencies declarative, so other tools can read them as well.

For now only pkg-config dependencies are supported, but we are planning to expand it at some point.

Users can override dependency flags using environment variables if needed. system-deps also allows -sys crates to optionally internally build and static link the required system library.

system-deps has been started as a fork of the metadeps project.

Documentation

See the crate documentation.

Usage

In your Cargo.toml:

[build-dependencies]
system-deps = "2.0"

Then, to declare a dependency on testlib >= 1.2 add the following section:

[package.metadata.system-deps]
testlib = "1.2"

Finally, in your build.rs, add:

fn main() {
    system_deps::Config::new().probe().unwrap();
}

See the crate documentation for more advanced features.

system-deps's Issues

Add support for declaring linkage to system/platform libraries

Examples of this would be e.g. the whole zoo of libraries Windows ships, like bcrypt.dll or kernel32.dll (the latter is already pulled in by std of course).

Having these listed in the Cargo.toml would help in case of building a staticlib as all these libraries will also have to be provided again when linking the final build result (executable or shared library). By having them listed in Cargo.toml they could be extracted from there for later usage.

See also mesonbuild/meson#11789

Add support for providing version ranges to pkg-config

This needs calling https://docs.rs/pkg-config/latest/pkg_config/struct.Config.html#method.range_version and some syntax for specifying this in Cargo.toml.

Support static linking

I'm currently trying to figure out how to support static linking of libraries.
It seems that's a rather tricky task, as pkg-config doesn't seem to provide a way (at least pub) to check if the library is static (via pkg_config::Config::probe).

I've seen that pkg_config::Config::cargo_metadata is set to false everywhere where it is used (as this is apparently done in this lib), Is there a reason for not using pkg-config's cargo_metadata? As setting it to true does have the desired effect of hinting cargo that the desired lib is static (and not printing it in this lib).

Could avoid querying pkg-config with multiple times the same package

There is a regression in pkgconf which breaks system-deps:
pkgconf/pkgconf#310

Could system-deps be a bit more clever and avoid querying multiple times the same package?

Environment variables for pkg-config override

There should be a common pattern for these so that one can set CFLAGS, LIBS, LDFLAGS for each dependency individually so that pkg-config is not called. I would suggest METADEPS_${DEPENDENCY_NAME}_CFLAGS, etc.

Please include LICENSE files

AIUI both Apache-2.0 and MIT require the license text to be included with the source.
See also joshtriplett#8.

Inaccurate docs about toml

https://docs.rs/system-deps/latest/system_deps/#overriding-library-name

toml keys cannot contain dot characters

I don't think this is true, the following should work (and, adguably, should be recommended?)

[package.metadata.system-deps]
"glib-2.0" = "2.64"

https://toml.io/en/v1.0.0#keys

3.1.0 fails to build on powerpc64le-unknown-freebsd

I'm running FreeBSD/powerpc64le system and try to build librsvg2-rust-2.52.0. It bundles system-deps 3.2.0.
Unfortunately, building fails during build of system-deps with:
thread 'main' panicked at 'Invalid TARGET: powerpc64le-unknown-freebsd', /wrkdirs/usr/ports/graphics/librsvg2-rust/work/librsvg-2.52.0/vendor/system-deps/src/lib.rs:735:32

Rust itself has support for powerpc64le-unknown-freebsd target:

root@powerpc64le-130-default:/usr/ports/graphics/librsvg2-rust # rustc --print target-list | grep powerpc64le-unknown-freebsd
powerpc64le-unknown-freebsd
root@powerpc64le-130-default:/usr/ports/graphics/librsvg2-rust # rustc -V --verbose
rustc 1.55.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: powerpc64le-unknown-freebsd
release: 1.55.0
LLVM version: 12.0.1

test failed in fedora copr

https://download.copr.fedorainfracloud.org/results/remilauzier/gtk/fedora-rawhide-x86_64/02305147-rust-system-deps/builder-live.log.gz

Support passing pkg-config a triple-specific env variables

It should mimic cargo use of triples for the compiler env.

provide a way for users/meson to pass specific pc file

While discussing with @ndufresne about gst-plugin-rs's meson integration we figured that meson could detect the presence of an optional dep using pkg-config and cargo/system-deps could end up using another pc file that the one detected by meson, typically if user used the pkg_config_path meson option, leading to confusion.

Maybe meson could communicate somehow to system-deps the full path of the pc files it detected making sure both are using the same one?

Support target specific dependencies

At librsvg we have a dependency on pangoft2 and fontconfig, but not if you are building for Windows. I'd like to be able to express such a target-specific dependency using system_deps. Is that already possible, is such a feature planned?

Hook for libraries without pkg-config support

This could then be used to run things like sdl2-config, and similar to retrieve the same information. Crates could provide code to extract these things and then provide the same information as pkg-config to metadeps.

Removing dependencies

Someone opened an issue on gtk-rs gtk-rs/gtk-rs-core#225 about the fact that this crate was problematic because it weighted heavily on the build process. Would you be open for me to remove dependencies (while keeping the same features!)?

Need support for depending on a specific pkg-config file only if a specific feature is enabled

See https://github.com/gtk-rs/cairo/blob/master/cairo-sys-rs/build.rs

cairo-gobject should only be checked/pulled in if the glib feature is enabled. I believe that's currently not possible to express

Support configuring per-feature pkg-config names

In GStreamer the GL library was split from one big pkg-config file into separate ones per platform (EGL, X11, Wayland) plus the main one (GL).

For backwards compatibility in the crate for gstreamer-gl-x11-sys (for example) it would be needed to depend on gstreamer-gl-1.0 for versions < 1.18 and on gstreamer-gl-x11-1.0 for versions >= 1.18.

Similarly gstreamer-gl-x11 would have to depend on the gstreamer-gl-sys crate (with "x11" feature) for < 1.18 and on gstreamer-gl-x11-sys (without any features) for >= 1.18.

I don't think either of this can currently be expressed.

Environment variable override to request building the C dependency as part of the crate for crates that support this

METADEPS_${DEPENDENCY_NAME}_BUILD_INTERNAL or similar. This would have to come with a hook in build.rs or so, so that metadeps can a) error out if not supported by the crate, b) call into crate specific code for actually building.

The crate specific code then has to provide CFLAGS, LIBS, LDFLAGS etc back to metadeps.

As part of this it would also be useful to make it an error if two crates in the dependency chain build the same library.

are you able to support musl based rust targets?

hey there,

it just happened that I ran into an issue compiling librsvg with a musl based armv7a toolchain. rustc is armv7a-unknown-linux-musleabihf , still I end up with this error when compiling your system-deps crate:

env RUST_BACKTRACE=1 make -j4
make  all-recursive
make[1]: Entering directory '/tmp/librsvg'
Making all in .
make[2]: Entering directory '/tmp/librsvg'
cd . &&                                                 \
PKG_CONFIG_ALLOW_CROSS=1                                                \
PKG_CONFIG='/usr/bin/pkg-config'                                                \
CARGO_TARGET_DIR=/tmp/librsvg/target                                    \
cargo --locked build   --release --lib \
&& cd /tmp/librsvg && /bin/sh ./libtool --silent --tag=CC   --mode=link gcc  -g -O2   -o librsvg_c_api.la _rsvg_dummy.lo && mv /tmp/librsvg/target/release/liblibrsvg.a .libs/librsvg_c_api.a
   Compiling librsvg v2.55.0 (/tmp/librsvg)
   Compiling selectors v0.23.0
   Compiling rayon v1.6.0
   Compiling url v2.3.1
error: failed to run custom build command for `librsvg v2.55.0 (/tmp/librsvg)`

Caused by:
  process didn't exit successfully: `/tmp/librsvg/target/release/build/librsvg-e80ec40cb3b31f0b/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=CAIRO_PDF_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=SYSROOT
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=CAIRO_PS_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=SYSROOT
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=CAIRO_SVG_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=SYSROOT
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a-unknown-linux-musleabihf
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_armv7a_unknown_linux_musleabihf
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'Invalid TARGET: armv7a-unknown-linux-musleabihf', /root/.cargo/registry/src/github.com-1285ae84e5963aae/system-deps-6.0.3/src/lib.rs:807:32
  stack backtrace:
     0: rust_begin_unwind
     1: core::panicking::panic_fmt
     2: system_deps::Config::check_cfg::{{closure}}
     3: core::option::Option<T>::unwrap_or_else
     4: system_deps::Config::check_cfg
     5: system_deps::Config::probe_pkg_config
     6: system_deps::Config::probe_full
     7: system_deps::Config::probe
     8: build_script_build::main
     9: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
make[2]: *** [Makefile:1554: librsvg_c_api.la] Error 101
make[2]: Leaving directory '/tmp/librsvg'
make[1]: *** [Makefile:1077: all-recursive] Error 1
make[1]: Leaving directory '/tmp/librsvg'
make: *** [Makefile:712: all] Error 2

Can you maybe improve the target detection, to allow for musleabihf instead of gnueabihf?

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

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?

can't detect library

Hello! Thank you for this crate first of all :)

I'm using Arch linux and if I execute the following:

cd /usr/lib
rg --files | rg libgbm

than I'm getting the following output:

libgbm.so.1.0.0

in other words, /usr/lib/libgbm.so.1.0.0 exist.

But if I have the following in my Cargo.toml:

[package.metadata.system-deps]
libgbm = "1.0.0"

I'm getting the following error message, if I try cargo build:

  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: PkgConfig(`PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" "pkg-config" "--libs" "--cflags" "libgbm" "libgbm >= 1.0.0"` did not exit successfully: exit status: 1
  error: could not find system library 'libgbm' required by the 'rust_tmp' crate

May I ask what I'm doing wrong?

Reproduction steps

I created a repository for you, so you don't need to create directories and stuff through the terminal. Just clone my repository and run cargo build. You'll just need to take a look into the build.rs and Cargo.toml :) I hope it helps!

Support PKG_CONFIG_PATH with multiple paths

I'm under NixOS, with a shell.nix the PKG_CONFIG_PATH can have multiple paths like this:

["/nix/store/jpxl50sf957jrw0cwihvfs6sjzas3195-libopus-1.3.1-dev/lib/pkgconfig:/nix/store/gn82z1l1gka3ij4d4qnn5yqqn2vmkghg-libvpx-1.9.0-dev/lib/pkgconfig:/nix/store/7yhr6c2jqnynp2pr4ydg1laz3mmf9si4-SDL2-2.0.14-dev/lib/pkgconfig:/nix/store/5vpabs61whm6jba3nm6gjzvwasl7ngrd-libGL-1.3.2-dev/lib/pkgconfig:/nix/store/gk6yyb6h14idrdp9gdnpv79arxn9bjsv-libglvnd-1.3.2-dev/lib/pkgconfig:/nix/store/hk902lcky48myw0smia39c8864filn1z-libX11-1.7.0-dev/lib/pkgconfig:/nix/store/kh0h5if5pwqhj7iph5cxyqwdv7fvnb2g-xorgproto-2020.1/share/pkgconfig:/nix/store/4p2zc0k3mhg2c6cg1b9i1njnkf8xl5k5-libxcb-1.14-dev/lib/pkgconfig:/nix/store/jpxl50sf957jrw0cwihvfs6sjzas3195-libopus-1.3.1-dev/lib/pkgconfig:/nix/store/gn82z1l1gka3ij4d4qnn5yqqn2vmkghg-libvpx-1.9.0-dev/lib/pkgconfig:/nix/store/7yhr6c2jqnynp2pr4ydg1laz3mmf9si4-SDL2-2.0.14-dev/lib/pkgconfig:/nix/store/5vpabs61whm6jba3nm6gjzvwasl7ngrd-libGL-1.3.2-dev/lib/pkgconfig:/nix/store/gk6yyb6h14idrdp9gdnpv79arxn9bjsv-libglvnd-1.3.2-dev/lib/pkgconfig:/nix/store/hk902lcky48myw0smia39c8864filn1z-libX11-1.7.0-dev/lib/pkgconfig:/nix/store/kh0h5if5pwqhj7iph5cxyqwdv7fvnb2g-xorgproto-2020.1/share/pkgconfig:/nix/store/4p2zc0k3mhg2c6cg1b9i1njnkf8xl5k5-libxcb-1.14-dev/lib/pkgconfig"]

Currently from_internal_pkg_config panics with:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: JoinPathsError { inner: JoinPathsError }'

because env::join_paths doesn't support : inside a path.

Enviroment variable to disable system-deps

I am using gvsbuild to compile a gtk application on windows (I have other dependencys that won't compile under MSYS). Before the gtk-rs release a few weeks ago I could compile with:

${Env:RUSTFLAGS} = "-L C:\gtk-build\gtk\x64\release\lib"; cargo build

Now that gtk-rs uses system-deps I have to disable each dependency individually, which results in:

${Env:SYSTEM_DEPS_glib_2_0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_glib_2_0_LIB} = "glib-2.0"; 
${Env:SYSTEM_DEPS_cairo_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_cairo_LIB} = "cairo"; 
${Env:SYSTEM_DEPS_cairo_gobject_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_cairo_gobject_LIB} = "cairo-gobject"; 
${Env:SYSTEM_DEPS_gobject_2_0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_gobject_2_0_LIB} = "gobject-2.0"; 
${Env:SYSTEM_DEPS_atk_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_atk_LIB} = "atk-1.0"; 
${Env:SYSTEM_DEPS_pango_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_pango_LIB} = "pango-1.0"; 
${Env:SYSTEM_DEPS_gio_2_0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_gio_2_0_LIB} = "gio-2.0"; 
${Env:SYSTEM_DEPS_gdk_pixbuf_2_0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_gdk_pixbuf_2_0_LIB} = "gdk_pixbuf-2.0"; 
${Env:SYSTEM_DEPS_gdk_3_0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_gdk_3_0_LIB} = "gdk-3.0"; 
${Env:SYSTEM_DEPS_gtk+_3_0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_gtk+_3_0_LIB} = "gtk-3.0"; 
${Env:SYSTEM_DEPS_GTK+_3.0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_GTK+_3.0_LIB} = "gtk-3.0"; 
${Env:SYSTEM_DEPS_gtk_3_0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_gtk_3_0_LIB} = "gtk-3.0"; 
${Env:SYSTEM_DEPS_GTK_3.0_NO_PKG_CONFIG} = 1; 
${Env:SYSTEM_DEPS_GTK_3.0_LIB} = "gtk-3.0"; 
${Env:RUSTFLAGS} = "-L C:\gtk-build\gtk\x64\release\lib"; 
cargo build

Would it be possible to add somthing like SYSTEM_DEPS_DISABLE?

version feature naming restriction is problematic

Hi,

I'm exploring switching my libpulse_sys crate and its companions over to system-deps from pkg-config. Converting to v1.3 it seems to work, but upgrading to v2.0 I'm getting an error:

cargo:warning=Unexpected key package.metadata.system-deps.libpulse.pa_v12 type table

Could you please take a look.

I've pushed the change to my next branch: https://github.com/jnqnfe/pulse-binding-rust/tree/next

The second to last commit there is the conversion to v1.3 and the last commit is the problematic upgrade to v2.0.

Thanks. :)

vcpkg support

Hi!

I'm trying to setup a CI on github actions to build a rust gtk app. This is not an easy task. I'm using vcpkg with visual studio 2019 as a compiler.

Would it be possible / is it an idea at all to add vcpkg support to this system-deps repository?

Regards,
Windel

Retrieving all aggregated include/flags/etc for the entire probe

I need to build a small C library from build.rs (see below for an example), so I am using the cc crate, however there is no "simple" way to get all the include_paths. I have to use libs.get("foo").unwrap().include_paths.clone(); but this has various issues:

1. I have to know that "foo" pulls in the other deps, or manually get all includes and aggregate them
2. The hashtable returned by probe() mangles the library name, so for instance get("gdk-pixbuf-2.0") fails, because the actual key in the map is gdk_pixbuf_2_0, but the caller has no way to know this.

Maybe probe should actually return a new type rather than the raw hash table.

    let libs = system_deps::Config::new().probe();
    if let Err(s) = libs {
        println!("cargo:warning={}", s);
        process::exit(1);
    }

    let libs = libs.unwrap();
    let includes = libs.get("foo").unwrap().include_paths.clone();

    let mut cc = cc::Build::new();

    cc.file("tests/constant.c");
    cc.file("tests/layout.c");

     for i in includes {
        cc.include(i);
    }

    cc.compile("cabitests");

Cargo.toml used by tests are not included in the generated package

It seems the tests are failing because the tests directory in the crate does not contain all the subdirectory like in the repo:

$ ll tests/
drwxr-xr-x@   - bob 12 Jul 20:09 toml-missing-file
.rw-r--r--@ 468 bob  1 Jan  1970 testanotherlib.pc
.rw-r--r--@ 176 bob  1 Jan  1970 testdata.pc
.rw-r--r--@ 229 bob  1 Jan  1970 testlib-2.0.pc
.rw-r--r--@ 229 bob  1 Jan  1970 testlib-3.0.pc
.rw-r--r--@ 290 bob  1 Jan  1970 testlib.pc

Shouldn't all the tests subdirectories be included in the crate?