This also means when XCODE_SCHEME_WORKING_DIRECTORY is
set and a Xcode generator is used, that property will be used when
writing the debugger field in the file API replies.
Fixes: #26909
bf1bb62e74 macOS: Restore support for LLVM/Clang without explicit CMAKE_OSX_SYSROOT
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10734
In commit 7b19531291 (macOS: Do not pass any SDK/-isysroot to compilers
by default, 2024-11-06, v4.0.0-rc1~511^2) we broke support for using
upstream LLVM/Clang to build for macOS because the compiler has no
default sysroot. Handle empty `CMAKE_OSX_SYSROOT` with LLVM/Clang by
falling back to the macOS SDK reported by `xcrun --show-sdk-path` .
Fixes: #26863
In commit e90f60f864 (find_package: Don't glob certain macOS paths,
2024-10-23, v4.0.0-rc1~579^2~1) we changed the name matching logic of
`find_package` to check if a possible match is a directory before
checking whether the name is a match. In some situations, this results
in unnecessarily calling `stat` for a very large number of files, which
can be extremely slow on some systems (especially Windows). Fix this by
making the check the last thing we do before accepting a possible match.
Fixes: #26817
CPS names look like `[package]:component`, which needs to get mangled
into `package::component` to match CMake's convention. This was
implemented correctly for fully qualified component requirements, but
relative names were not being properly mangled. Adjust handling of
relative names to correctly translate from CPS to CMake convention.
In commit f2596dfa0e (macOS: Work around bug in system curl 8.{3,4,5}
LibreSSL backend, 2024-07-16, v3.30.1~2^2) we tried to prefer
`secure-transport` on problematic versions of curl. However, the
`curl_global_sslset` setting must be applied before every
`curl_global_init` call, not just the first one. Otherwise a
second (or subsequent) download won't apply the work-around.
In commit 5aed3ee49d (cmSystemTools: Add GetLogicalWorkingDirectory,
2024-10-28, v4.0.0-rc1~528^2~6) we incorrectly trusted `PWD` to be a
normalized path so long as its realpath matches the current working
directory.
Fixes: #26870
Some CoreFoundation headers included by the umbrella header, which we do
not need, use syntax that GCC does not support. Avoid including them.
GCC-Issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880
5805461074 cmSystemTools: Simplify call to FindProgram for our own executable
db0e2574cb cmSystemTools: Restore FindProgram look-up of on-disk case on Windows
5d700abda4 Source: Simplify FindProgram calls
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10620
Remove the unnecessary `FindProgramPath` wrapper. Call the KWSys
`FindProgram` directly, without our CMake-specific wrapper, since
we follow-up with a `ToNormalizedPathOnDisk` anyway.
KWSys's `FindProgram` no longer looks up the actual case on disk. This
behavior change was inherited from the change to `CollapseFullPath`.
Extend commit 773b75e4ed (cmake: Explicitly look up on-disk case of
input paths on Windows, 2024-10-23, v4.0.0-rc1~589^2) to cover this by
wrapping `FindProgram` in a CMake-specific layer.
Issue: #20214
This was accidentally dropped by commit 622596c6b2 (cmSystemTools:
Re-implement ToNormalizedPathOnDisk without translation map, 2024-10-30,
v4.0.0-rc1~528^2~5). Previously it was done by `CollapseFullPath`.
`cm::PathResolver` intentionally does not expand `~` because it makes
sense only for transforming input paths. Teach `ToNormalizedPathOnDisk`
to handle it directly.
Fixes: #26827
Do not try to load a CPS file if we've already loaded the same file.
This only works if the current `find_package` call selects the same file
as the previous most recent call, and if the user has not meddled with
the `<name>_CONFIG` variable.
Issue: #26731
Fix logic to populate required and optional components from CMake
variables when `find_package` is called in a nested context.
This was broken in commit e2a6416622 (find_package: Refactor in support
of recursion, 2024-11-29, v4.0.0-rc1~356^2), which promoted the
component sets from locals (in cmFindPackageCommand::InitialPass) to
member variables. Previously, in a nested context, these sets were
simply not filled, and we relied on the variables indicating component
requirement to already be set. When logic was added to properly fill the
sets (which is needed for CPS), it blindly dumped all components into
the required set, without actually checking whether the context had
marked the components as required or optional.
Fixes: #26824
Revert commit c554437733 (get_filename_component: Fix REALPATH for ..
after symlink, 2024-11-21, v4.0.0-rc1~411^2) because it changed existing
behavior without a policy. Also add a test case for the old behavior.
Note that we have policy `CMP0152` to fix this for `file(REAL_PATH)`,
but it does not affect `get_filename_component(... REALPATH)`. A new
policy would be needed for the latter.
Fixes: #26815
Issue: #26472
Updates the hash in snippet file naming to take the ProcessId into account
so that snippets with identical commands don't risk a collision in filename.
Additionally, this adds a `workingDir` to snippet files so that snippets with
identical commands can be more easily differentiated, such as with install
snippets.
Since commit c8997fc046 (export: Allow depending on targets exported
multiple times, 2024-12-26, v4.0.0-rc1~241^2), it is possible to depend
on a target exported multiple times so long as the target is exported in
only one set and with a consistent namespace. However, as a
side-effect, a target could not be in multiple export sets even if only
one of those sets was installed.
Update the check so that uninstalled export sets do not count towards a
target being exported multiple times.
Fix two minor issues with how default configurations are set from CPS
packages. First, imported configurations were (appropriately) being
converted to upper case, but default configurations weren't. Second,
default configurations were being set only after importing components
from the root package configuration file, resulting in configurations
specified in the root file preceding the default configurations.
In commit 95323c90a1 (file(MAKE_DIRECTORY): Add optional RESULT keyword
to capture failure., 2024-06-16, v3.31.0-rc1~414^2) we computed an
updated range of arguments, that name directories to be created, before
the `RESULT` keyword. However, we forgot to use it in the loop.
Fixes: #26768
In commit 95323c90a1 (file(MAKE_DIRECTORY): Add optional RESULT keyword
to capture failure., 2024-06-16, v3.31.0-rc1~414^2) we computed an
updated range of arguments, that name directories to be created, before
the `RESULT` keyword. However, we forgot to use it in the loop.
Fixes: #26768
In commit 823e1df54c (cmSystemTools: Implement GetRealPath on Windows,
2024-11-04, v4.0.0-rc1~521^2~1) we implemented the POSIX behavior that
resolves symlinks followed by '..' components. However, Windows just
removes them lexically. Also, we were not handling all junction types.
Instead, use `GetFinalPathNameByHandleW` via `uv_fs_realpath`.
Note that we previously attempted this in commit 640709e7db
(cmSystemTools: Implement GetRealPath on Windows, 2017-10-02,
v3.11.0-rc1~445^2~1) but reverted it in commit 83630d4918
(cmSystemTools: Revert GetRealPath implementation on Windows,
2018-05-29, v3.11.3~3^2) due to resolving `subst` drives. This time,
add code to re-`subst`itute the drive in the resolved path.
Fixes: #26750
Issue: #17206
We need it to restore behavior on Windows. Revert commit 16af27fd42
(cmSystemTools: Drop GetRealPathResolvingWindowsSubst, 2024-11-04,
v4.0.0-rc1~521^2), but with a cleaned up implementation.
Issue: #26750
Issue: #18033
Since upstream curl commit `2ec00372a1` (curl.h: change some enums to
defines with L suffix, 2025-02-25), the `CURL_NETRC_*` constants are
integer literals instead of `enum CURL_NETRC_OPTION`. It turns out
that `curl_easy_setopt` has always expected a `long` anyway, and
that `CURL_NETRC_OPTION` is not documented for public use.
Fixes: #26754
Since commit 622596c6b2 (cmSystemTools: Re-implement
ToNormalizedPathOnDisk without translation map, 2024-10-30,
v4.0.0-rc1~528^2~5) we normalize input paths, while resolving symlinks
only if followed by `..` components, by using `cm::PathResolver`'s
`LogicalPath` mode. However, that approach assumes POSIX semantics for
resolving paths with symlinks and is incorrect on Windows.
On Windows, file system operations naively remove any component
preceding `..` regardless of whether it is a symlink. Prior to the
above commit, `ToNormalizedPathOnDisk` matched that behavior using
`CollapseFullPath` followed by `GetActualCaseForPath`. Restore it using
`cm::PathResolver`'s `CasePath` mode.
Issue: #26750
In CMake 3.31 and below, `CollapseFullPath` did this on Windows. KWSys
has since stopped looking up the on-disk case in `CollapseFullPath` to
avoid disk access when most callers only need an in-memory operation.
We currently call `GetActualCaseForPath` explicitly when needed.
Add a mode to `cm::PathResolver` to combine these operations and cache
disk access behind the `System::ReadName` callback. We will use this to
restore the way CMake 3.31 and below normalized input paths on Windows.
Issue: #26750
Issue: #20214
e9c494005c cmake-gui: Fix regression that prints an incidental error on fresh build trees
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10429
