No way to determine build directory in `cmake -C InitialCache.txt -B dir`

In my <initial-cache> script specified with -C, I want to set some variables depending on the build path supplied via -B:

cmake -C foo.txt -S src -B my-build-dir

Problem:

There are no variables that contain my-build-dir. The obvious variable, $CMAKE_BINARY_DIR, is set to $PWD instead of the build directory as I would expect. Later in the configuration process, $CMAKE_BINARY_DIR is set to my-build-dir as expected.

I have tried the trick mentioned in here to look at all variables, but none of them contain the directory of interest.

I could make a directory, then cd there, but I want to take advantage of the fact that -B creates the directory for you, so the build process can become a single cmake invocation rather than mkdir $x; cd $x; cmake -C ../foo.txt ../src.

changed title from No way to determine build directory in cmake -C InitialCache.txt to No way to determine build directory in cmake -C InitialCache.txt{+ -B dir+}

For reference, the initial cache file is loaded while processing the -C option here. It is loaded very early so most values are not yet set. Some investigation would be needed to determine whether CMake internally even knows the values at that point. If not then some refactoring may be needed.

I looked into it briefly.

CMake does know the value by the time you reach ReadListFile, it's in this->GetHomeOutputDirectory(). But then it is overwritten with this->SetHomeOutputDirectory(cmSystemTools::GetCurrentWorkingDirectory());.

Looking into the history, I found this commit from 2005 where the behaviour was changed. Unfortunately the commit message contains no information about the bug that was being fixed, and it is unclear how the change fixes the bug.

If I remove the lines which set the home directory and output directory, then things work as I would expect.

mentioned in merge request !3709 (merged)

I've submitted a merge request for what I just described in !3709 (merged).

That commit from 2005 established the behavior of -P scripts having these variables set to the working directory. That was back in wild west days with no review or testing requirements.

The -C option is currently processed as soon as it is seen, but it may be followed by -S or -B options that change the relevant directories. Refactoring will be needed to record the list of -C options and process it after the final directories are known in order to achieve the behavior requested here regardless of what variables hold the values.

The -C option is currently processed as soon as it is seen, but it may be followed by -S or -B options that change the relevant directories.

Based on my reading of the source, I don't think that's true. It is processed in SetCacheArgs, called here whereas SetArgs parses -B and -S and is called earlier.

It is not clear whether the existing values should be changed, even with a policy. Let's keep design discussion over in #19619 (closed).

I agree, it's unclear to me. I submitted the patch to stimulate discussion.

Fair enough, the -P behaviour needs to be preserved.

What of the behaviour for PreLoad.cmake and -C? Is my request reasonable?

The documentation for CMAKE_BINARY_DIR and CMAKE_SOURCE_DIR is confusing given the current behaviour, at least.

I have a suggestion for a simple implementation that I haven't yet found a refutation of - in the -P path, do this:

      this->SetHomeDirectory(cmSystemTools::GetCurrentWorkingDirectory());
      this->SetHomeOutputDirectory(cmSystemTools::GetCurrentWorkingDirectory());
      this->ReadListFile(args, path);

Done in this update.

Suggestion on how to test the behaviour of -P is welcomed.

closed via merge request !3709 (merged)

closed via commit 4ca0526f

mentioned in issue #19827 (closed)

mentioned in merge request !3912 (merged)