# cmake v3.29.1 regression (up to cmake 3.29 is fine)
**URL:** https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628
**Category:** Development
**Tags:** os:linux, os:windows, os:macos
**Created:** [April 10, 2024, 8:25pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628 "2024-04-10T20:25:05Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Gonzalo\_Garramuno](https://discourse.cmake.org/u/Gonzalo_Garramuno)
#### Post date: [April 10, 2024, 8:25pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/1 "2024-04-10T20:25:05Z")
find\_package() seems to be using or mangling the casing of paths when run, at least, from ExternalProject\_Add.
Find attached a self-contained project that aborts with an error in find\_package(). It builds OpenColorIO (a color management library after building its dependencies and then tries to find it with find\_package()). Before v3.29.1 the build would work. With v3.29.1 it fails finding the libraries.
[build\_ocio.tar.gz](https://discourse.cmake.org/uploads/short-url/AmFnBFS49gC4nRy3PTOxyXL1spR.gz) (30 KB)
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 10, 2024, 10:19pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/2 "2024-04-10T22:19:17Z")
@craig.scott this bisects to [CMake MR 9390](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9390).
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 10, 2024, 10:26pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/3 "2024-04-10T22:26:58Z")
In OpenColorIO [this code](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/v2.3.2/src/cmake/Config.cmake.in#L17-L19) is using a `PACKAGE_PREFIX_DIR` variable that `CMakePackageConfigHelpers`, in CMake 3.29.0 and below, generates as an implementation detail. 3.29.1 uses a different variable name.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 10, 2024, 10:34pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/4 "2024-04-10T22:34:39Z")
It seems projects have been treating the undocumented `PACKAGE_PREFIX_DIR` implementation detail as if it were part of the public interface. See also [CMake Issue 25873](https://gitlab.kitware.com/cmake/cmake/-/issues/25873)
---
### Author:  [@Gonzalo\_Garramuno](https://discourse.cmake.org/u/Gonzalo_Garramuno)
#### Post date: [April 11, 2024, 1:09pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/5 "2024-04-11T13:09:26Z")
As a user of OpenColorIO (not a developer for it), I reverted back to v3.29.0 for my CI builds.
However, moving forward, I would like to know what’s the suggested solution (revert v3.29.2 to 3.29.0 behavior --variable–, propose a real documented API variable, make all packages that depend on this old behavior change their code, or something else?).
---
### Author:  [@Gonzalo\_Garramuno](https://discourse.cmake.org/u/Gonzalo_Garramuno)
#### Post date: [April 11, 2024, 1:13pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/6 "2024-04-11T13:13:37Z")
Never mind. I just saw the “regression” commit by Brad King. Thanks for your hard-work!!!
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 11, 2024, 1:20pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/7 "2024-04-11T13:20:02Z")
[CMake MR 9420](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9420) reverts the change. I’ve re-opened [CMake Issue 25827](https://gitlab.kitware.com/cmake/cmake/-/issues/25827) to discuss the problem that originally motivated the change.
---
### Author:  [@traversaro](https://discourse.cmake.org/u/traversaro)
#### Post date: [April 12, 2024, 1:44pm UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/8 "2024-04-12T13:44:19Z")
For reference, we also were using `PACKAGE_PREFIX_DIR` as part of the public interface in matio-cpp ([CI Failure April 2024 · Issue #78 · ami-iit/matio-cpp · GitHub](https://github.com/ami-iit/matio-cpp/issues/78)), but we fixed that on our side in [InstallBasicPackageFiles: Fix bug of OVERRIDE\_MODULE\_PATH that corrupt CMAKE\_MODULE\_PATH values set by blf transitive dependencies and fix OVERRIDE\_MODULE\_PATH with CMake 3.29.1 by traversaro · Pull Request #79 · ami-iit/matio-cpp · GitHub](https://github.com/ami-iit/matio-cpp/pull/79/commits/20ed96890dcc83baae4b82788831792fd17cf5ea) .
---
### Author:  [@Mathieu\_Westphal](https://discourse.cmake.org/u/Mathieu_Westphal)
#### Post date: [April 14, 2024, 7:50am UTC](https://discourse.cmake.org/t/cmake-v3-29-1-regression-up-to-cmake-3-29-is-fine/10628/9 "2024-04-14T07:50:15Z")
F3D is impacted as well.
We were using it because `@PACKAGE_INIT@` expand to
```auto
get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../" ABSOLUTE)
```
And find it useful.
We just define it ourself now: [Fix incorrect usage of internal variable PACKAGE\_PREFIX\_DIR by mwestphal · Pull Request #1377 · f3d-app/f3d · GitHub](https://github.com/f3d-app/f3d/pull/1377)