Non-deterministic file(GLOB_RECURSE) ordering undermines build reproducibility - CMake

Answer to the question

As of CMake 3.20 and newer, there is no built‑in option, policy, or variable that forces file(GLOB_RECURSE) to return a sorted list. The documentation explicitly states that the order of the returned file list is unspecified and may change between releases. The only supported way to obtain a deterministic order is to sort the list yourself immediately after the GLOB_RECURSE call, using list(SORT).

Supported pattern

• Execute file(GLOB_RECURSE VAR RECURSE "*.cpp") (or whatever pattern you need).
• Follow it directly with list(SORT VAR).
  • Because list(SORT) performs a byte‑wise lexicographic comparison (essentially strcmp), the resulting order is identical on any platform that presents the same byte sequences for each path.
• Use the sorted variable for downstream commands such as add_library, add_executable, or test discovery scripts.

Platform and filesystem caveats

• Path separators: Windows file(GLOB) returns paths with backslashes (\), while Unix‑like systems use forward slashes (/). Sorting the raw strings will produce different orders unless you normalise the separator first (e.g., string(REPLACE "\\" "/" …)).
• Unicode normalization: Filesystems such as macOS HFS+ may store Unicode names in a composed form, whereas Linux ext4 typically uses a decomposed form. Since list(SORT) compares raw bytes, the relative order of two files that differ only in Unicode normalization can change across systems. Normalising the strings (e.g., to NFC) before sorting is required for reproducibility when such filenames exist.
• Duplicate entries: list(SORT) guarantees stable ordering for duplicate strings, but duplicates are identical and do not affect the final set of unique files.

When will list(SORT) still produce different orders?

Only in the two scenarios above—different separator styles or differing Unicode representations—will the sorted order diverge. If your source tree contains no such variations, the sorted list will be identical across machines and CMake versions.

What to check in your environment

If your build system still shows non‑deterministic ordering after applying list(SORT), consider:

• Do any source files use non‑ASCII characters that might be stored in different Unicode normal forms?
• Are you mixing Windows and Unix path separators in the same list?

Answering these questions will help determine whether additional normalisation steps are necessary.

Conclusion

In short: CMake has no built‑in option to sort GLOB_RECURSE results. The documented, supported pattern is to call list(SORT) immediately after the glob. On typical file systems this yields a stable order, but you must account for path separator and Unicode normalization differences if your source tree contains such variations.