# Testing/simulating a missing dependency

**URL:** https://discourse.cmake.org/t/testing-simulating-a-missing-dependency/15804
**Category:** Usage
**Created:** [August 25, 2026, 7:35am UTC](https://discourse.cmake.org/t/testing-simulating-a-missing-dependency/15804 "2026-08-25T07:35:36Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![ferdnyc](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ferdnyc/32/267_2.png) [@ferdnyc](https://discourse.cmake.org/u/ferdnyc)
#### Post date: [August 25, 2026, 7:35am UTC](https://discourse.cmake.org/t/testing-simulating-a-missing-dependency/15804/1 "2026-08-25T07:35:36Z")

</div>

Say I have a project that includes Bison and Flex code, and therefore relies on `FindBISON.cmake` and `FindFLEX.cmake`. (Because, I do.) Say, also, that the project does not `REQUIRE` those dependencies in the `find_package()` calls, but rather configures them as `REQUIRED`after-the-fact using `set_package_properties()`, so that they can be reported as `REQUIRED` by `feature_summary()` at the end of the configuration process.

So IOW, given this minimal `CMakeLists.txt` :

```cmake
project(demo)

include(FeatureSummary)

find_package(BISON)
set_package_properties(BISON PROPERTIES TYPE REQUIRED)

BISON_TARGET(Parser fooparse.y fooparse.c)

add_executable(mytool mytool.c
  ${BISON_Parser_OUTPUTS}
)

feature_summary(WHAT ALL
  INCLUDE_QUIET_PACKAGES
  FATAL_ON_MISSING_REQUIRED_PACKAGES
)

```

Say I want to now _demonstrate_ why that project definition is a problem, and why the `BISON_TARGET` and `${BISON_Parser_OUTPUTS}` uses need to be wrapped in `if(BISON_FOUND)` checks lest they defeat the whole purpose of `set_package_properties(BISON PROPERTIES TYPE REQUIRED)` by crashing the configure run before it can ever reach `feature_summary()`. (Because, again, I do.)

I’d like to be able to demonstrate that a fixed version of the script, on a system without `bison`, will fail to configure with a missing required package error after `find_summary()`, rather than the `Unknown CMake command "BISON_TARGET"` failure mode of the unfixed script.

But I’d prefer to demonstrate that _without_ having to take the drastic step of **uninstalling** `bison` from the system in question. Except, I can’t seem to find a way to “simulate” a missing `bison` in a way that `feature_summary()` will still treat it as `REQUIRED`.

…How would I do that?

I thought at first I could use `-DCMAKE_DISABLE_FIND_PACKAGE_BISON=1` on the `cmake` command line. And while that does work for breaking the _unfixed_ version of the project configs (because the `BISON_TARGET` macro doesn’t exist), the problem is that _completely_ disables the `BISON` package in the build. That means that, in my fixed version of the script with `if(BISON_FOUND)` checks added, those checks will test `FALSE` **and** `BISON` will no longer be flagged as a missing required package by `feature_summary()`, meaning the configuration process completes successfully.

So, then I experimented with setting different cache variables related to the `FindBISON.cmake` discovery process. But setting `-DBISON_ROOT=<badpath>` doesn’t prevent it from discovering `/usr/bin/bison`, and if I set `-DBISON_EXECUTABLE=/some/nonsense/path -DBISON_FOUND=0` then CMake changes `BISON_FOUND` to `TRUE`when the `find_package()` call runs (reporting that it successfully found `BISON` at `/some/nonsense/path`), so again the config process completes successfully instead of erroring out at `feature_summary()`.

I’m kind of at a loss for how to tell CMake, “Pretend `bison` can’t be found by `find_package(BISON)`, and execute all of the normal logic that would be run when `bison` is **actually** not found.” in some relatively-simple way (ideally) using only command-line arguments. Rather than having to alter the system in some way, like uninstalling `bison` or writing my own `FindBISON.cmake` module to override the built-in one.

Is there some solution I’m missing?
