# Improved framework for writing find-modules

**URL:** https://discourse.cmake.org/t/improved-framework-for-writing-find-modules/7317
**Category:** Development
**Created:** [January 25, 2023, 4:25pm UTC](https://discourse.cmake.org/t/improved-framework-for-writing-find-modules/7317 "2023-01-25T16:25:11Z")
**Posts on this page:** 1
**Showing post:** 11

<div class="post-metadata">

### Author: ![dabrahams](https://discourse.cmake.org/user_avatar/discourse.cmake.org/dabrahams/32/4265_2.png) [@dabrahams](https://discourse.cmake.org/u/dabrahams)
#### Post date: [March 25, 2024, 7:25pm UTC](https://discourse.cmake.org/t/improved-framework-for-writing-find-modules/7317/11 "2024-03-25T19:25:04Z")

</div>

> The only variable that is still a must-define is the `<packageName>_FOUND` variable, which indicates the `find_package()` call was successful, and the `find_package()` command will ensure that is set unless the config file or Find module explicitly sets it to false.

Unless `FetchContent_MakeAvailable` is setting that variable, that is not consistent with the results I’m seeing. I am setting up `CMAKE_MODULE_PATH` to point at a repository of Find modules—used across my suite of projects—that mostly just `FetchContent_Declare` and `FetchContent_MakeAvailable` (and maybe apply some workarounds that haven’t been upstreamed yet). Then I just use `find_package` and it works without complaint.

> In short, avoid writing Find modules at all if you can

I’ve been planning to create my own “rails,” but this and other statements above makes me think I’m heading off in the wrong direction. That said, using FindModules is the only clean solution I’ve found to the problems outlined in [this post](https://discourse.cmake.org/t/how-to-vend-dependency-information-configuration/10319/3).

---

_[View the full topic](https://discourse.cmake.org/t/improved-framework-for-writing-find-modules/7317)._
