# Questions about \`--find-package\` CLI & MSVC

**URL:** https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194
**Category:** Usage
**Created:** [July 31, 2022, 11:59pm UTC](https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194 "2022-07-31T23:59:52Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![h-vetinari](https://discourse.cmake.org/user_avatar/discourse.cmake.org/h-vetinari/32/2207_2.png) [@h-vetinari](https://discourse.cmake.org/u/h-vetinari)
#### Post date: [July 31, 2022, 11:59pm UTC](https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194/1 "2022-07-31T23:59:52Z")

</div>

The output of `cmake --help` says

```auto
  --find-package = Legacy pkg-config like mode. Do not use.

```

However, incorrect CMake metadata it is one of the possible failure modes in integration work like conda-forge does (not least since some packages contain some unholy mess of build hacks, mostly upstream directly, or occasionally also in conda-forge itself for various reasons).

To catch such failures early, I want to test that the packaged `lib/cmake/<pkg>/<pkg>Config.cmake` etc. work correctly. A bit of googling [later](https://stackoverflow.com/a/28863712), I found I could successfully do

```auto
cmake --find-package -DNAME=zstd -DLANGUAGE=C -DMODE=EXIST -DCOMPILER_ID=GNU # [linux]
cmake --find-package -DNAME=zstd -DLANGUAGE=C -DMODE=EXIST -DCOMPILER_ID=Clang # [osx]

```

## First question is: what is a non-legacy way to do the same thing?

The second question is why the windows version

```auto
cmake --find-package -DNAME=zstd -DLANGUAGE=C -DMODE=EXIST -DCOMPILER_ID=MSVC # [win]

```

fails with:

```auto
CMake Error at D:/bld/zstd-split_1659310630313/_test_env/Library/share/cmake-3.23/Modules/Platform/Windows-MSVC.cmake:67 (message):
  MSVC compiler version not detected properly:
Call Stack (most recent call first):
  D:/bld/zstd-split_1659310630313/_test_env/Library/share/cmake-3.23/Modules/Platform/Windows-MSVC-C.cmake:1 (include)
  D:/bld/zstd-split_1659310630313/_test_env/Library/share/cmake-3.23/Modules/CMakeCInformation.cmake:48 (include)
  D:/bld/zstd-split_1659310630313/_test_env/Library/share/cmake-3.23/Modules/CMakeFindPackageMode.cmake:116 (include)

CMake Error: Run 'cmake --help' for all supported options.

```

Unfortunately, the recommended-by-the-error `cmake --help` does not show any useful way of what to change (except a list of generators, but adding `-GNinja` also doesn’t change anything either).

Thanks in advance for any help on this. 🙂

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 2, 2022, 11:19am UTC](https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194/2 "2022-08-02T11:19:28Z")

</div>

There’s no replacement for `--find-package` because it doesn’t work with targets all that well.

As for MSVC, you need to call it from a developer prompt or load `vcvarsall.bat` manually. It works with the other compilers because they “just work” with the path. MSVC doesn’t work that way, but CMake always assumes that the compiler is usable in the given environment (except for IDE generators where it is assumed the IDE knows how to use the toolchain itself…which is usually true).

---

<div class="post-metadata">

### Author: ![h-vetinari](https://discourse.cmake.org/user_avatar/discourse.cmake.org/h-vetinari/32/2207_2.png) [@h-vetinari](https://discourse.cmake.org/u/h-vetinari)
#### Post date: [August 2, 2022, 1:40pm UTC](https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194/3 "2022-08-02T13:40:55Z")

</div>

Thanks for the response!

> [@ben.boeckel](#):
>
> There’s no replacement for `--find-package` because it doesn’t work with targets all that well.

OK. But cmake will presumably still produce metadata files that will be used internally whenever `find_package` is called. As an integrator (especially a cross-platform one), it’s essential that there’s some way to test that this metadata is correct – unfortunately we don’t have the luxury of letting everything be handled by CMake; some projects don’t have native CMake integration, or it doesn’t match how our distribution works (no static libs except in rare cases), or is flat-out wrong, or, or, or…, so this is not a hypothetical scenario.

For example, I recently encountered

```auto
CMake Error at $PREFIX/lib/cmake/zstd/zstdTargets.cmake:87 (message):
  The imported target "zstd::libzstd_static" references the file

     "$PREFIX/lib/libzstd.a"

  but this file does not exist. Possible reasons include:
  * The file was deleted, renamed, or moved to another location.
  * An install or uninstall procedure did not complete successfully.
  * The installation package was faulty and contained
     "$PREFIX/lib/cmake/zstd/zstdTargets.cmake"
  but not all the files it references.

Call Stack (most recent call first):
  $PREFIX/lib/cmake/zstd/zstdConfig.cmake:1 (include)
  cmake/config-ix.cmake:149 (find_package)
  CMakeLists.txt:768 (include)

-- Configuring incomplete, errors occurred!

```

I’d like to catch this at the source (in this case the testing phase of `zstd`), and currently `cmake --find-package` fits the bill. What will I be able to use to test something like that, once `--find-package` is removed?

I also don’t fully understand why a compiler is necessary – couldn’t the existence of files referenced in `<pkg>Targets.cmake` be tested more trivially?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 2, 2022, 9:31pm UTC](https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194/4 "2022-08-02T21:31:18Z")

</div>

> [@h-vetinari](#):
>
> As an integrator (especially a cross-platform one), it’s essential that there’s some way to test that this metadata is correct

Add tests which perform `find_package()` from CMake and make small programs or whatever just by linking to the target(s) as needed. This will at least test that the CMake integration is correct. Bonus points for running the tests against an install tree and not just the build tree. As for providing the relevant information for non-CMake projects:

> [@h-vetinari](#):
>
> couldn’t the existence of files referenced in `<pkg>Targets.cmake` be tested more trivially?

`find_package` modules can do a lot of things. For example, `FindMPI` ends up needing to know the compiler for $reasons. I think `FindHDF5` is similar. The most robust that I’ve been able to come up with is [this script](https://gitlab.kitware.com/paraview/paraview/-/blob/master/CMake/paraview-config.cmake.in) which basically generates a small project and then logs the build to extract out the flags that actually matter. You might be able to do it more statically if you know there aren’t more fancy usage requirements (compile flags, link flags, etc.) or the dependency graph is “simple”.

You might be able to generate this for a given install prefix and install it as a `.pc` file or something for more direct usage (though your project is then non-relocatable as far as this information is related).

---

<div class="post-metadata">

### Author: ![h-vetinari](https://discourse.cmake.org/user_avatar/discourse.cmake.org/h-vetinari/32/2207_2.png) [@h-vetinari](https://discourse.cmake.org/u/h-vetinari)
#### Post date: [August 2, 2022, 10:27pm UTC](https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194/5 "2022-08-02T22:27:38Z")

</div>

> [@ben.boeckel](#):
>
> Add tests which perform `find_package()` from CMake and make small programs or whatever just by linking to the target(s) as needed. This will at least test that the CMake integration is correct

OK fair, but that’s a bunch more test setup than a CLI invocation. For now, I guess I’ll stay with `--find-packages` until it breaks…

> [@ben.boeckel](#):
>
> Bonus points for running the tests against an install tree and not just the build tree.

Always 😁

Thanks for the help!

---

<div class="post-metadata">

### Author: ![h-vetinari](https://discourse.cmake.org/user_avatar/discourse.cmake.org/h-vetinari/32/2207_2.png) [@h-vetinari](https://discourse.cmake.org/u/h-vetinari)
#### Post date: [August 15, 2022, 8:14pm UTC](https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194/6 "2022-08-15T20:14:28Z")

</div>

> [@ben.boeckel](#):
>
> As for MSVC, you need to call it from a developer prompt or load `vcvarsall.bat` manually.

So I tried this with our compiler setup, and despite

```auto
CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.16 10.0.22000.0

```

passing successfully

```auto
** Visual Studio 2019 Developer Command Prompt v16.11.17
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

```

this still runs into “MSVC compiler version not detected properly”…

---

<div class="post-metadata">

### Author: ![h-vetinari](https://discourse.cmake.org/user_avatar/discourse.cmake.org/h-vetinari/32/2207_2.png) [@h-vetinari](https://discourse.cmake.org/u/h-vetinari)
#### Post date: [August 15, 2022, 8:21pm UTC](https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194/7 "2022-08-15T20:21:38Z")

</div>

This is exactly the same setup under which cmake would run in non-CLI mode as well, so it’s a bit frustrating that there’s zero info about which part of the version detection is failing, much less how to fix it.