I'm testing out some new Linux builds of tectonic using vcpkg-rs. My cargo build commands works OK, but cargo test doesn't because of missing symbols. As far as I can tell, the root cause is that the link information being emitted by vcpkg-rs doesn't tell Rust that it should be linking with static libraries. That is, the output from build.rs is like this:

cargo:rustc-link-search=native=/home/peter/sw/tex/tectonic/target/vcpkg/installed/x64-linux/lib
cargo:rustc-link-lib=harfbuzz-icu
cargo:rustc-link-lib=harfbuzz

instead of rustc-link-lib=static=harfbuzz, etc.

I notice that there used to be a test for vcpkg_target.is_static that would emit the static= variant, but it was removed in 3429248 . It is not obvious to me what the motivation for that was, but my best understanding is that there should be a codepath that at least makes sure that static= comes back on Linux static builds.

vcpkg-rs has not been published in a while. The last version of vcpkg-rs was published in 2021.

I am hitting issues where rust is not able to detect the VCPKG as VCPKG_ROOT is different from VCPKG_INSTALLED_ROOT

Trying the latest master the issue is fixed but i am unable to use it since the package has not been published.

I installed cairo like this:

vcpkg install cairo

And I'm trying to find it like this in my build.rs

vcpkg::find_package("cairo").unwrap();

However, it fails to find the library

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: LibNotFound("cairo")', src\libcore\result.rs:997:5

Similarly, vcpkg_cli can't find it either

> vcpkg_cli probe cairo
Failed:  Could not find library in Vcpkg tree cairo

I verified that it's in the vcpkg list, I'm not sure where the problem is.

I am wonder, is it true or not.

In general, dynamic builds are installed in vcpkg\triplet\bin, but user has to add them to the PATH manually I guess. So cargo will build them, but builten executables won't be able to run without dependent DLLs.

Hi, I invoke this crate

//main.rs
extern crate vcpkg;
fn main(){
	let opencv = vcpkg::find_package("opencv4").unwrap(); 
	dbg!(&opencv);
}

#cargo.toml
[package]
name = "find_opencv"
version = "0.1.0"
authors = ["dzwei <[email protected]>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
vcpkg = "0.2.8"

These env. I've set

VCPKG_ROOT: C:\SDKs\vcpkg
VCPKGRS_DYNAMIC: 1

I got following error message

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target\debug\find_opencv.exe`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotMSVC', src\libcore\result.rs:1188:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: process didn't exit successfully: `target\debug\find_opencv.exe` (exit code: 101)

but if I use vcpkg_cli , it can be found:

$ vcpkg_cli.exe probe opencv4
Found library opencv4
Include paths:
  C:\SDKs\vcpkg\installed\x64-windows\include
Library paths:
  C:\SDKs\vcpkg\installed\x64-windows\lib
Runtime Library paths:
  C:\SDKs\vcpkg\installed\x64-windows\bin
Cargo metadata:
  cargo:rustc-link-search=native=C:\SDKs\vcpkg\installed\x64-windows\lib
  cargo:rustc-link-search=native=C:\SDKs\vcpkg\installed\x64-windows\bin
  cargo:rustc-link-lib=opencv_calib3d
  cargo:rustc-link-lib=opencv_core
  cargo:rustc-link-lib=opencv_dnn
  cargo:rustc-link-lib=opencv_features2d
  cargo:rustc-link-lib=opencv_flann
  cargo:rustc-link-lib=opencv_highgui
  cargo:rustc-link-lib=opencv_imgcodecs
  cargo:rustc-link-lib=opencv_imgproc
  cargo:rustc-link-lib=opencv_ml
  cargo:rustc-link-lib=opencv_objdetect
  cargo:rustc-link-lib=opencv_photo
  cargo:rustc-link-lib=opencv_stitching
  cargo:rustc-link-lib=opencv_video
  cargo:rustc-link-lib=opencv_videoio
  cargo:rustc-link-lib=libwebpmux
  cargo:rustc-link-lib=webp
  cargo:rustc-link-lib=webpdecoder
  cargo:rustc-link-lib=webpdemux
  cargo:rustc-link-lib=tiff
  cargo:rustc-link-lib=tiffxx
  cargo:rustc-link-lib=zlib
  cargo:rustc-link-lib=lzma
  cargo:rustc-link-lib=jpeg
  cargo:rustc-link-lib=turbojpeg
  cargo:rustc-link-lib=libpng16
  cargo:rustc-link-lib=libprotobuf-lite
  cargo:rustc-link-lib=libprotobuf
  cargo:rustc-link-lib=libprotoc
Found DLLs:
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_calib3d.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_core.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_dnn.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_features2d.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_flann.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_highgui.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_imgcodecs.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_imgproc.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_ml.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_objdetect.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_photo.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_stitching.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_video.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\opencv_videoio.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\libwebpmux.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\webp.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\webpdecoder.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\webpdemux.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\tiff.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\zlib1.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\lzma.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\jpeg62.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\turbojpeg.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\libpng16.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\libprotobuf-lite.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\libprotobuf.dll
  C:\SDKs\vcpkg\installed\x64-windows\bin\libprotoc.dll
Found libs:
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_calib3d.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_core.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_dnn.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_features2d.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_flann.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_highgui.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_imgcodecs.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_imgproc.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_ml.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_objdetect.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_photo.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_stitching.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_video.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\opencv_videoio.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\libwebpmux.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\webp.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\webpdecoder.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\webpdemux.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\tiff.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\tiffxx.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\zlib.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\lzma.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\jpeg.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\turbojpeg.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\libpng16.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\libprotobuf-lite.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\libprotobuf.lib
  C:\SDKs\vcpkg\installed\x64-windows\lib\libprotoc.lib
Libraries linking names:
  opencv_calib3d
  opencv_core
  opencv_dnn
  opencv_features2d
  opencv_flann
  opencv_highgui
  opencv_imgcodecs
  opencv_imgproc
  opencv_ml
  opencv_objdetect
  opencv_photo
  opencv_stitching
  opencv_video
  opencv_videoio
  libwebpmux
  webp
  webpdecoder
  webpdemux
  tiff
  tiffxx
  zlib
  lzma
  jpeg
  turbojpeg
  libpng16
  libprotobuf-lite
  libprotobuf
  libprotoc

I sure I have install opencv4:x64-windows with vcpkg:

$ vcpkg list opencv
opencv4:x64-windows                                4.1.1-3          computer vision library
opencv4[dnn]:x64-windows                                            Enable dnn module
opencv4[jpeg]:x64-windows                                           JPEG support for opencv
opencv4[opengl]:x64-windows                                         opengl support for opencv
opencv4[png]:x64-windows                                            PNG support for opencv
opencv4[tiff]:x64-windows                                           TIFF support for opencv
opencv4[webp]:x64-windows                                           WebP support for opencv

So vcpkg-rs cannot find opencv4,
I'm confused...

It looks like CI is broken on the rust 1.10.0 compile test:

Run cargo build --manifest-path vcpkg/Cargo.toml --verbose
warning: unused manifest key: package.categories
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: failed to parse registry's information for: rand

Caused by:
  Feature `std_rng` depends on `rand_hc` which is not an optional dependency.
Consider adding `optional = true` to the dependency

Potential solutions seem a bit limited, as the 1.10.0 doesn't support the following:

• Replace crates-io source is supported at 1.12 docs
• Replace a dependency with a patch is supported at 1.21: docs

Another way to "fix" could be to have the integration test mirror and rollback crates.io to before the rand crate breakage, and point at this crates.io source repo with a bumped-up rust version 1.12.0.

Hi.
Fedora would like to have the readme and all the license file in the crate source to be able to package them.
Thanks for your time.
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_documentation

graphite2 has description text on multiple lines, which can't be parsed by current code.

@mcgoo Hi, which kind of error is represented by NotMVC and why exactly does it exist? Was it a workaround for a bug or limitation of vcpkg? If so, can you link the issue?

EDIT: corrected from NoMSVC to NotMSVC

Hi everybody,

Great work on this project.

We found that the code contains some changes that will make this crate work in our vcpkg manifest mode scenario.

We have a blocker because we can't publish a package to a registry because for these features we have to reference the crate from git instead of crates.io

What would be necessary to release a new version to crates.io containing the latest changes? Is there any way I can assist?

Shouldn't vcpkg-rs automatically set to static/dynamic rather than requiring this env var to be set by default. Users just building this library as a dependency won't know to set this env var unless they dig through the the problem

I didn't figure out this was causing my build to fail since it was a nested dependency. And digging further revealed it is caused by this library.

C:\Users\Swoorup.Joshi\Documents\git\vcpkg [master ≡]
λ  vcpkg_cli.exe probe sqlite3
Failed:  Aborted because VCPKGRS_DYNAMIC is not set

@waych @mcgoo Now that the latest PRs have been merged in, is it time to release things to Crates.io?

Side note: for my personal work I have been getting super enthusiastic about release automation with a custom workflow+tool that I've developed, called Cranko. I would definitely not suggest trying to jump into using it for this project right now, but I am eager to spread the word because it's really transforming how I approach these matters.

I'm using some dependencies which use this crate to link C/C++ libraries on windows (For example leptonica and tesseract).

I am trying to enable cross-language LTO on a build targeting x86_64-pc-windows-msvc. This requires compiling C/C++ code using an LLVM compiler, which means not using MSVC's cl.exe compiler. I have gotten it to compile using clang-cl instead of MSVC's cl.exe and lld-link.exe instead of link.exe manually building the C/C++ code and instructing my dependencies via env vars to not use this crate and instead use the libs I generated, but I think ideally vcpkg can be made to work with it.

I found this issue microsoft/vcpkg#2087 about clang-cl support in vcpkg, which was closed and vcpkg does not support a triplet for it, not as an official triplet, nor as a community maintained triplet shipped with vcpkg. However, vcpkg has support for "custom triplets" which are even less supported than community and you have to manually add to the vcpkg/triplets folder. And in that issue, someone shared their github repository with custom triplets which includes a x64-windows-llvm triplet that uses clang-cl. I'm opening this issue to check/discuss if somehow (Maybe through an environment variable) custom vcpkg triplet support would be in scope for this crate.

I am essentially thinking of something like:

REM I manually make a triplet file for vcpkg and add it to vcpkg/triplets before installing libs and then run this
set VCPKGRS_TRIPLET_OVERRIDE=x64-windows-llvm-thinlto
cargo build --release

Is there a way to specify a specific library to use within a vcpkg package?

As an example the nrf-ble-driver vcpkg/cmake package provides several libraries one can link towards.

Here is the output from vcpkg install nrf-ble-driver:

 find_package(nrf-ble-driver CONFIG REQUIRED)
    # Note: 4 target(s) were omitted.
    target_link_libraries(main PRIVATE nrf::nrf_ble_driver_sd_api_v2_shared nrf::nrf_ble_driver_sd_api_v2_static nrf::nrf_ble_driver_sd_api_v3_shared nrf::nrf_ble_driver_sd_api_v3_static)

In a typical C based application this would be done like this in the CMakeLists.txt file:

  target_link_libraries(${APPLICATION} PRIVATE
        nrf::nrf_ble_driver_sd_api_v5_shared
        Threads::Threads
        spdlog::spdlog
        Catch2::Catch2
    )

Is it possible, for example, to specify that the rust library shall use the nrf::nrf_ble_driver_sd_v5_shared and not all libraries found in the package?

Hi. i am trying too package vcpkg-rs in fedora and the test failed because the test-data are not include in the crate source.
https://download.copr.fedorainfracloud.org/results/remilauzier/rust-simp/fedora-rawhide-x86_64/02251202-rust-vcpkg/builder-live.log.gz
At the end of the log you can see the issue.
Thanks for your time.

Hi,

I am attempting ton compile a rust program using libxml2 crate that uses vcpkg::find_package function to check if lib sources are available in the system.

For now, using stable-x86_64-msvc rust toochain with vcpkg x64-windows triplet, all is working as expected.

The next step is trying to switch to the GNU world, using x86_64-pc-windows-gnu rust toolchain with vcpkg x64-mingw-dynamic triplet, but vcpkg::find_package fails.

Is there any planned work to make vcpkg-rs compatible with GNU mode ?

Thks for your work :).

I have run vcpkg integrate install, I have installed zlib on it.
I have set rustflags = ["-Ctarget-feature=+crt-static"].

Getting

thread 'main' panicked at 'called Result::unwrap() on an Err value: LibNotFound("zlib")', libcore\result.rs:945:5
note: Run with RUST_BACKTRACE=1 for a backtrace.

I have no idea how to debug this and how do I get an running vcpkg_cli command for console.

Currently, it looks like the way library discovery works with vcpkg-rs is by greping the .list manifest in load_port_manifest.

This causes libraries discovered in the probe to be linked in the alphabetical order listed in the manifest.

This week I've been digging through trying to unblock the CI for rust-sdl2 (which uses cargo-vcpkg for sdl2 packages) here: Rust-SDL2/rust-sdl2#1085

The first issue was fixed in upstream vcpkg (fixing the windows-latest CI), but then broke on ubuntu-latest due to a problem linking libraries from the brotli port. The core of the issue is that it links "-lbrotlicommon-static -lbrotlidec-static -lbrotlienc-static" which breaks with the --as-needed flag passed to the linker, as symbols are discarded from the "common" lib before the "enc" and "dec" libs are added to the link.

I sent microsoft/vcpkg#16992 as a workaround which just includes common in "dec" and "enc", which can unblock the CI for rust-sdl2, but I think the right thing here is for vcpkg-rs to learn how to look at the .pc files installed that describe the ordering relationship.

I will look a bit at how hard this is to do, but would like your opinion and direction as to how this should look.

The doc says:

You must set one of RUSTFLAGS=-Ctarget-feature=+crt-static or VCPKGRS_DYNAMIC=1 in your environment ...

But if you set only RUSTFLAGS=-Ctarget-feature=+crt-static, vcpkg-rs is still unable to find a package.

When building a crate with the x86_64-unknown-linux-musl target, vcpkg exits with a NotMSVC error. If musl is not supported, it should print a more specific error.

Note that

Example of vcpkg-configuration.json below. How to use a setup like this with cargo-vcpkg in the Cargo.toml file?

% cat vcpkg-configuration.json 
{
    "default-registry": {
        "kind": "git",
        "repository": "https://github.com/microsoft/vcpkg",
        "baseline": "11ed79186fe850bd3a98cfbf1854514d2b3070a2"
    },
    "registries": [
        {
            "kind": "git",
            "repository": "https://github.com/REGISTRY_NUMBER_ONE/vcpkg-registry",
            "baseline": "eddf13fee1813c50542a5665e103ed144d451db2",
            "packages": ["libsodium", "libsecp256k1"]
        },
        {
            "kind": "git",
            "repository": "https://github.com/SECOND_REGISTRY_DIFFERENT_PLACE/vcpkg-registry",
            "baseline": "04305f55e7ffb8f8662ab1d05c34fd3a90cf7556",
            "packages": ["protobuf", "etc_you_get_the_idea"]
        }
    ]
}

Hi, want to supply the include paths to cc when building a -sys crate. However it seems there's no way to do this?

Hey everyone 👋
I was looking into vcpkg and how it could work with cargo and Rust and found this crate. I like how easily the integration works with the build.rs file, but since I would like to use the "version" feature of vcpkg. Yet versions are only supported in the manifest mode in which dependencies are read from the manifest file and then being installed in the project directory.

I had a look at the code and noticed that, to support manifest mode, the paths like e.g. status_path, lib_path, bin_path etc. need to be changed. Hardcoding a different root directory seemed to easily allow me to use this crate even in manifest mode.

Now I would like to discuss how to go about this. In manifest mode, a vcpkg.json file exists in the root of the Rust project. Would it make sense to check the existence of such a file and then automatically make the adjustments to the paths? Or should the user set an environment variable to let the crate now that it should look for packages in the project directory first? Or maybe it should always check the project directory first?

I'm hoping that we can make this crate even better! If we find a valid approach I can give it a go to implement it myself and then create a pull request.

Best regards,
Björn

vcpkg could make use of a vcpkg-sys crate that will use cc crate to compile vcpkg itself. And by having vcpkg project and ports as a git submodule, this would enable vcpkg-sys to provide all the files necessary (except CMake and MSVC build tools obviously) to build C and C++ native libraries to use as Rust dependencies.

Creating a cargo-vcpkg plugin to download and build vcpkg packages would improve drastically the user experience on Windows when using MSVC toolchain.

Imagine:

c:\rust\relm> cargo vcpkg gtk
c:\rust\relm> cargo run --example button

Better yet if somewhat the first step could be done via a build.rs script in gtk-rs itself.
By having vcpkg embedded, all native libraries may end in the project target folder or in .cargo folder and be dependent of toolchain version.

Now that Vcpkg supports OSX and Linux, would you be interested in PR's enabling support on those platforms?

Currently, the triplets are named x64-osx and x64-linux and they only build static libs -- there is no -static suffix and there are no dynamic variants.

Hey there,

Would it be possible to configure the VCPKGRS_* environmental variables from the Config object exposed by the library, with the library setting overridden by the environment?

This would allow us to manage this for different targets in build.rs, aiming to simplify the build process for *-sys crate consumers.

Somewhat related issue: rust-embedded#481

Cheers,

Ryan

@mcgoo had started transitioning cargo-vcpkg sourtces out of this repo, and into mcgoo/cargo-vcpkg, so that the underlying rustc version dependency can be decoupled. This is because vcpkg would like to remain compatible with as far back a version of Rust as possible, yet cargo-vcpkg wants to take on newer dependencies so that it can look at newer cargo metadata.

Completing this transition has become desirable considering the Fedora issues filed today, which motivate re-organizing this repo a bit. #33 and #35 both occur because the vcpkg crate is not published with these files, and moving vcpkg sources to the top-level should easily fix that problem. This seems like a natural cleanup next step after cargo-vcpkg gets moved out to the new repo.

If no-one complains, I'll take a stab at the above in the next day or so.

fn ios() {
    // vcpkg::find_package("icu").unwrap(); // this would build the whole rust lib but the compilation for iOS using xcode would fail due to missing symbols
    println!("cargo:rustc-link-search=native=path/to/vcpkg/installed/arm64-ios-simulator/lib");
    println!("cargo:rustc-link-lib=static=icuuc");
    println!("cargo:rustc-link-lib=static=icui18n");
    println!("cargo:rustc-link-lib=static=icudata");

only adding static= to the lib being linked can fix

https://doc.rust-lang.org/cargo/reference/build-scripts.html#:~:text=other%20linker%20options.-,cargo%3A%3Arustc%2Dlink%2Dlib%3DLIB,%2C%20or%20framework.%20See%20the%20rustc%20book%20for%20more%20detail.,-cargo%3A%3Arustc%2Dlink

Is there a way to specify this kind?

For example, loading "harfbuzz[icu]".

Currently, it seems that vcpkg searches for libraries using either the package name or libraries specified with Config::lib_name. However, this breaks with some packages that produce a library with a version number and configuration in the filename (e.g. with the zeromq package: libzmq-mt-4_2_3.lib).
Would it be possible to query vcpkg for the actual library name instead of inferring it from the package name? The actual library name is present in the CMake files (vcpkg/packages/<package-config>/share/<package-name>/)
For now, one possible workaround for those packages is to hard-code the library name with the version and pass it to Config::lib_name, but this breaks as soon as the package is updated.

Hi, I ran into some unexplained trouble although following the readmes step by step. The steps below are what I exactly did. How could I solve it?

1. in Cargo.toml

[dependencies]
vcpkg = "0.2.10"

[package.metadata.vcpkg]
git = "https://github.com/microsoft/vcpkg"
rev = "56fffbe"

[package.metadata.vcpkg.target]
x86_64-pc-windows-msvc = { triplet = "x64-windows-static", install = ["tesseract"] }

2. cargo vcpkg build

3. vcpkg_cli probe -l static tesseract

Found library tesseract
Include paths:
  D:\x\target\vcpkg\installed\x64-windows-static\include
Library paths:
  D:\x\target\vcpkg\installed\x64-windows-static\lib
Runtime Library paths:
Cargo metadata:
  cargo:rustc-link-search=native=D:\x\target\vcpkg\installed\x64-windows-static\lib
  cargo:rustc-link-lib=tesseract41
  cargo:rustc-link-lib=leptonica-1.78.0
  cargo:rustc-link-lib=zlib
  cargo:rustc-link-lib=tiff
  cargo:rustc-link-lib=tiffxx
  cargo:rustc-link-lib=lzma
  cargo:rustc-link-lib=jpeg
  cargo:rustc-link-lib=turbojpeg
  cargo:rustc-link-lib=libwebpmux
  cargo:rustc-link-lib=webp
  cargo:rustc-link-lib=webpdecoder
  cargo:rustc-link-lib=webpdemux
  cargo:rustc-link-lib=libpng16
  cargo:rustc-link-lib=gif
Found libs:
  D:\x\target\vcpkg\installed\x64-windows-static\lib\tesseract41.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\leptonica-1.78.0.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\zlib.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\tiff.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\tiffxx.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\lzma.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\jpeg.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\turbojpeg.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\libwebpmux.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\webp.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\webpdecoder.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\webpdemux.lib
  D:\x\target\vcpkg\installed\x64-windows-static\lib\gif.lib
Libraries linking names:
  tesseract41
  leptonica-1.78.0
  tiff
  tiffxx
  lzma
  jpeg
  libwebpmux
  webp
  webpdecoder
  webpdemux
  libpng16
  gif

4. in main.rs

fn main() {
    vcpkg::find_package("tesseract").unwrap();
}

5. cargo run

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotMSVC', src\main.rs:2:38

There was discussion in #56/#57 about breaking changes, upping MSRV, etc. I wanted to collect thoughts/ideas/etc somewhere, and a list of things desired for a next update.
@waych / @pkgw feel free to comment on anything to add/remove from this list.

• Bump MSRV
  • Hard to find really good numbers, but https://lib.rs/stats#rustc implies that of the top 4000 crates, only a handful compile on rustc older than 1.31, so if we want to be 'maximally compatible', that might be a good number
  • Alternatively, 1.40 gets us #[non_exhaustive], which would help reduce breakage by allowing public structs and enums that can be later extended.
  • 1.56 is the next major bump in how many crates support it, so is probably the most logical choice after the above
• Delete deprecated things
• Fix NotMSVC error codes / spaghetti target code
• Improve type extensibility, make some stuff private
• General cleanup - #57 is a start on this
• Add support for determining library versions - #56, on the list because it requires breaking Library