# Should find\_package() skip empty PATH entries?

**URL:** https://discourse.cmake.org/t/should-find-package-skip-empty-path-entries/15385
**Category:** Development
**Created:** [December 11, 2025, 5:15am UTC](https://discourse.cmake.org/t/should-find-package-skip-empty-path-entries/15385 "2025-12-11T05:15:33Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![solarispika](https://discourse.cmake.org/user_avatar/discourse.cmake.org/solarispika/32/3276_2.png) [@solarispika](https://discourse.cmake.org/u/solarispika)
#### Post date: [December 11, 2025, 5:15am UTC](https://discourse.cmake.org/t/should-find-package-skip-empty-path-entries/15385/1 "2025-12-11T05:15:33Z")

</div>

## Summary

When the system `PATH` environment variable contains empty entries (e.g., `;;` on Windows or `::` on Unix), `find_package()` unexpectedly searches the current working directory. This happens because empty PATH entries are passed to path resolution functions that convert `""` to CWD.

I’d like to discuss whether filtering empty PATH entries in `find_package()` would be a reasonable enhancement.

## The Issue

On Windows, it’s common for the system PATH to contain empty entries:

- Trailing semicolon: `C:\bin;C:\tools;`
- Double semicolons: `C:\bin;;C:\tools`

These malformed entries often come from buggy installers and are difficult for users to notice.

When `find_package()` processes `CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH`, it iterates through PATH entries. Empty entries get passed to `CollapseFullPath("")`, which correctly resolves them to the current working directory (since `""` is a valid relative path meaning “current directory”).

## Reproduction

```cmake
cmake_minimum_required(VERSION 3.20)
project(test)

# Simulate empty PATH entry
set(ENV{PATH} "C:/bin;;C:/tools")

# Create a config file in build directory
file(WRITE "${CMAKE_BINARY_DIR}/mylib-config.cmake" "set(mylib_FOUND TRUE)")

# This finds mylib because "" resolves to CMAKE_BINARY_DIR
find_package(mylib CONFIG QUIET)
if(mylib_FOUND)
    message(WARNING "mylib found unexpectedly in: ${mylib_DIR}")
endif()

```

## Impact

This becomes problematic when:

1. CMake runs with CWD set to the build directory (common in IDE integrations)
2. The build directory contains `*-config.cmake` files from `export(TARGETS ...)`
3. System PATH has empty entries

In this case, `find_package(foo)` may incorrectly find packages exported to the build tree, even when `foo_ROOT` or `CMAKE_PREFIX_PATH` isn’t set.

## Proposal

Would it be reasonable for CMake to filter empty entries when processing PATH for `find_package()` searches? Something like:

```cpp
// When iterating PATH entries for find_package search
if (pathEntry.empty()) {
    continue; // Skip empty entries
}

```

This would be a defensive enhancement that prevents unexpected behavior from malformed PATH variables, which are unfortunately common on Windows systems.

## Workaround

Currently, users can work around this by filtering PATH at the start of CMakeLists.txt:

```cmake
if(WIN32)
  set(_path_sep ";")
else()
  set(_path_sep ":")
endif()
string(REPLACE "${_path_sep}" ";" _path_entries "$ENV{PATH}")
list(FILTER _path_entries EXCLUDE REGEX "^$")
list(JOIN _path_entries "${_path_sep}" _filtered_path)
set(ENV{PATH} "${_filtered_path}")

```

## Questions

1. Is this considered expected behavior, or would filtering empty PATH entries be a welcome enhancement?
2. If this is worth pursuing, should I file a GitLab issue?

Thanks for any feedback!

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [December 11, 2025, 1:52pm UTC](https://discourse.cmake.org/t/should-find-package-skip-empty-path-entries/15385/2 "2025-12-11T13:52:35Z")

</div>

> [@solarispika](#):
>
> If this is worth pursuing, should I file a GitLab issue?

Thanks for pointing this out. Yes, please open an issue.

---

<div class="post-metadata">

### Author: ![solarispika](https://discourse.cmake.org/user_avatar/discourse.cmake.org/solarispika/32/3276_2.png) [@solarispika](https://discourse.cmake.org/u/solarispika)
#### Post date: [December 12, 2025, 5:58am UTC](https://discourse.cmake.org/t/should-find-package-skip-empty-path-entries/15385/3 "2025-12-12T05:58:30Z")

</div>

Issue opened: [https://gitlab.kitware.com/cmake/cmake/-/issues/27454](https://gitlab.kitware.com/cmake/cmake/-/issues/27454)

---

<div class="post-metadata">

### Author: ![Helen-678](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/h/8baadc/32.png) [@Helen-678](https://discourse.cmake.org/u/Helen-678)
#### Post date: [December 31, 2025, 9:49am UTC](https://discourse.cmake.org/t/should-find-package-skip-empty-path-entries/15385/4 "2025-12-31T09:49:38Z")

</div>

Hey!!!

This is a common problem with CMake PATH: find\_package() isn’t really doing anything “wrong”; it just follows the rule that empty entries resolve to CWD.

In real life, it would be safer to filter out empty entries when going through PATH in find\_package(), especially on Windows where installers like to leave trailing semicolons.

Adding a flag or policy might be a more subtle way to fix the problem without breaking projects that depend on CWD resolution.

However, for most workflows, it makes sense to skip empty entries and avoid accidentally picking files from the build directory.

Yes, a defensive enhancement would keep things from going wrong without breaking the main logic.

---

<div class="post-metadata">

### Author: ![solarispika](https://discourse.cmake.org/user_avatar/discourse.cmake.org/solarispika/32/3276_2.png) [@solarispika](https://discourse.cmake.org/u/solarispika)
#### Post date: [January 3, 2026, 1:10pm UTC](https://discourse.cmake.org/t/should-find-package-skip-empty-path-entries/15385/5 "2026-01-03T13:10:35Z")

</div>

The behavior has changed since CMake 4.0 to remove empty PATH entries by default.

I was using CMake 3.31.6 and not noticing that change.

Therefore, the mentioned issue is closed now.