[cmake-developers] cmake 3.7.0-rc3 regression

[Brad King]

On 11/08/2016 01:59 PM, Robert Goulet wrote:
>     Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b
>     Add option to control 'bin' directory of CMake's own installation (#16076)

I suspect it is caused by this hunk:

> -  // Install tree has "<prefix>/bin/cmake" and "<prefix><CMAKE_DATA_DIR>".
> -  std::string dir = cmSystemTools::GetFilenamePath(exe_dir);
> -  cmSystemToolsCMakeRoot = dir + CMAKE_DATA_DIR;
> -  if (!cmSystemTools::FileExists(
> +  // Install tree has
> +  // - "<prefix><CMAKE_BIN_DIR>/cmake"
> +  // - "<prefix><CMAKE_DATA_DIR>"
> +  if (cmHasSuffix(exe_dir, CMAKE_BIN_DIR)) {
> +    std::string const prefix =
> +      exe_dir.substr(0, exe_dir.size() - strlen(CMAKE_BIN_DIR));
> +    cmSystemToolsCMakeRoot = prefix + CMAKE_DATA_DIR;
> +  }
> +  if (cmSystemToolsCMakeRoot.empty() ||
> +      !cmSystemTools::FileExists(

Prior to that we would blindly strip one directory off the location no
matter its name.  Now we need to look for and strip the exactly-configured
name of the bin directory because it may be more than one layer deep.

CMake locates its own resources relative to its executable in order to
make it relocatable.  This means we don't expect the layout of the install
tree to be changed after installation.  You're doing that, so your use case
is not supported.

However, what the above commit did was give you a first-class way of
supporting your use case by building with `CMAKE_BIN_DIR` set to the
platform-specific name.  You can use that to achieve the same result.

Alternatively, if you *really* want to support your original use case
you can work on a change to the above logic to count the number of path
components in CMAKE_BIN_DIR and strip that many blindly instead of looking
for the exact suffix.  I won't be holding up 3.7 for that though.

-Brad