CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-05-04T16:23:55-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16378cmake report detected ninja version not fit requirement when command not found2017-05-04T16:23:55-04:00comicfanscmake report detected ninja version not fit requirement when command not foundif previously build dir already configured , but ninja executable is moved, cmake didn't report
command not found ,but reports
"The detected version of Ninja ("") is less than the version of Ninja required by CMake ("1.3")
which is con...if previously build dir already configured , but ninja executable is moved, cmake didn't report
command not found ,but reports
"The detected version of Ninja ("") is less than the version of Ninja required by CMake ("1.3")
which is confused.
in cmGlobalNinjaGenerator.cxx:565
cmSystemTools::RunSingleCommand returns false , but there is no check on that.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16360Add support for Microsoft Build Tools 2015 in default generator selection2017-05-04T16:23:56-04:00Eduard WirchAdd support for Microsoft Build Tools 2015 in default generator selectionSee thread with the same name on the user mailing list.
I’ve installed build tools from here: http://landinghub.visualstudio.com/visual-cpp-build-tools.
But CMake will automatically detect (and choose) Visual Studio 8 (installed here...See thread with the same name on the user mailing list.
I’ve installed build tools from here: http://landinghub.visualstudio.com/visual-cpp-build-tools.
But CMake will automatically detect (and choose) Visual Studio 8 (installed here as well) instead.
Looking into the source:
const std::string vsregBase =
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\";
std::vector<std::string> vsVerions;
vsVerions.push_back("VisualStudio\\");
vsVerions.push_back("VCExpress\\");
vsVerions.push_back("WDExpress\\");
struct VSRegistryEntryName
{
const char* MSVersion;
const char* GeneratorName;
};
VSRegistryEntryName version[] = {
/* clang-format needs this comment to break after the opening brace */
{ "7.1", "Visual Studio 7 .NET 2003" },
{ "8.0", "Visual Studio 8 2005" },
{ "9.0", "Visual Studio 9 2008" },
{ "10.0", "Visual Studio 10 2010" },
{ "11.0", "Visual Studio 11 2012" },
{ "12.0", "Visual Studio 12 2013" },
{ "14.0", "Visual Studio 14 2015" },
{ "15.0", "Visual Studio 15" },
{ 0, 0 }
};
for (int i = 0; version[i].MSVersion != 0; i++) {
for (size_t b = 0; b < vsVerions.size(); b++) {
std::string reg = vsregBase + vsVerions[b] + version[i].MSVersion;
reg += ";InstallDir]";
cmSystemTools::ExpandRegistryValues(reg, cmSystemTools::KeyWOW64_32);
if (!(reg == "/registry")) {
installedCompiler = version[i].GeneratorName;
break;
}
}
}
CMake will look for `HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\InstallDir`. This key is not present indeed. When specified explicitly:
cmake . -G "Visual Studio 14 2015"
CMake will correctly detect the compiler and build without problems.
These keys might be helpful when looking for Build Tools:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\VC]
"ProductDir"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\"
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\SSDT]
"InstallDir"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\"
"VersionNumber"="14.0.50616.0"3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16288CMAKE_CROSSCOMPILING_EMULATOR breaks add_custom_command on imported targets2019-10-28T09:23:03-04:00Ennio BarbaroCMAKE_CROSSCOMPILING_EMULATOR breaks add_custom_command on imported targetsImporting an external executable via
```
add_executable(test_gen IMPORTED)
set_property(TARGET test_gen PROPERTY IMPORTED_LOCATION "${CMAKE_CURRENT_SOURCE_DIR}/build/test_gen")
```
And using it on a custom command with...Importing an external executable via
```
add_executable(test_gen IMPORTED)
set_property(TARGET test_gen PROPERTY IMPORTED_LOCATION "${CMAKE_CURRENT_SOURCE_DIR}/build/test_gen")
```
And using it on a custom command with:
```
add_custom_command(OUTPUT test.c COMMAND test_gen)
```
And invoking cmake with `-DCMAKE_TOOLCHAIN_FILE=/path/to/w64-mingw32-toolchain.cmake -DCMAKE_CROSSCOMPILING_EMULATOR=/path/to/wine/or/anything`
causes the name of the executable to be added as an additional argument (at least with Makefile and Ninja generators):
```
test.c:
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold --progress-dir=/home/ennio/cmake_test/test/build-mingw/CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Generating test.c"
../build/test_gen test_gen
```
Notice `test_gen` appended after `../build/test_gen`.
[Here](/uploads/18daa98566f3f594755096fb162a1183/crosscompile_gen_bug.tar.gz) is an SSCCE.
Using
```
get_target_property(somevar test_gen IMPORTED_LOCATION)
add_custom_command(OUTPUT test.c COMMAND ${somevar})
```
instead, or removing the `DCMAKE_CROSSCOMPILING_EMULATOR` directive works as expected. Notice that the cross-compiling emulator is not actually used in this context. CMake version is 3.6.1.
----------------
Background:
I am trying to cross-compile the Kf5 framework on archlinux using mingw. `uic`, `lconvert`and possibly other Qt-related commands fail due to this issue.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16278Wrong environment variable enconcoding on Windows after reading it from conso...2018-02-20T16:28:55-05:00Arkady ShapkinWrong environment variable enconcoding on Windows after reading it from console output and calling set() command for itUpdated: CMake change encoding for environment variables when you try reading it from console output and then set it back. My username contain Unicode symbols (Cyrillic), so `USERNAME` is also contains.
```cpp
execute_process(COMMAND...Updated: CMake change encoding for environment variables when you try reading it from console output and then set it back. My username contain Unicode symbols (Cyrillic), so `USERNAME` is also contains.
```cpp
execute_process(COMMAND cmd /C set USERNAME
OUTPUT_VARIABLE contents)
message(STATUS "contents ${contents}")
message(STATUS "$ENV{USERNAME}")
if(contents MATCHES "^([^=]+)=(.+)$")
set(ENV{${CMAKE_MATCH_1}} "${CMAKE_MATCH_2}")
endif()
message(STATUS "$ENV{USERNAME}")
```
After that my Windows app called from CMake doesn't work, because it uses `SHGetKnownFolderPath` (that use some of that environment variables) and it fails.
cmake version 3.6.03.8.0https://gitlab.kitware.com/cmake/cmake/-/issues/16253Xcode project generator omits `$(EFFECTIVE_PLATFORM_NAME)` from some paths wh...2020-03-06T08:00:44-05:00Mark RoweXcode project generator omits `$(EFFECTIVE_PLATFORM_NAME)` from some paths when generating project that supports multiple Apple platformsWhen generating an Xcode project intended to build for multiple Apple platforms (e.g., iOS and OS X), CMake omits `$(EFFECTIVE_PLATFORM_NAME)` from some paths in the project file. See the test project at https://github.com/bdash/cmake-xc...When generating an Xcode project intended to build for multiple Apple platforms (e.g., iOS and OS X), CMake omits `$(EFFECTIVE_PLATFORM_NAME)` from some paths in the project file. See the test project at https://github.com/bdash/cmake-xcode-multiplatform for a minimal test case demonstrating this, where CMake generates a project that is unable to build for the iPhone simulator, and may attempt to link a library built for OS X if the project is first built for that platform.
The underlying issue is that `cmGeneratorTarget::ComputeOutputDir` keys off `cmMakefile::PlatformIsAppleIos` to determine whether `$(EFFECTIVE_PLATFORM_NAME)` should be included in the path. This checks whether `CMAKE_OSX_SYSROOT` has a value that matches one of the known iOS platform names (iphoneos, iphonesimulator, etc). If `CMAKE_OSX_SYSROOT` is not explicitly specified, or has some other value, `$(EFFECTIVE_PLATFORM_NAME)` is omitted. Since the path to the output directory depends on the effective platform rather than a single SDK, `$(EFFECTIVE_PLATFORM_NAME)` should be included whenever the Xcode project generator is used.3.8.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16204Regex explorer does not match all2018-02-20T16:28:55-05:00Jean-Christophe Fillion-RobinRegex explorer does not match allAs highlighted in the screenshot below, only the first match is listed.
![regex_explorer_does_not_matchall](/uploads/6922be2025d1a09812e5c3d586fa5334/regex_explorer_does_not_matchall.png)
Thanks to Aron Ahmadia for reporting the pr...As highlighted in the screenshot below, only the first match is listed.
![regex_explorer_does_not_matchall](/uploads/6922be2025d1a09812e5c3d586fa5334/regex_explorer_does_not_matchall.png)
Thanks to Aron Ahmadia for reporting the problem.3.8.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/15955CMAKE-GUI creates varies with trailing blanks2018-12-07T09:57:15-05:00Kitware RobotCMAKE-GUI creates varies with trailing blanksThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15955). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15955). Further discussion may take place here.3.8.0Clinton StimpsonClinton Stimpsonhttps://gitlab.kitware.com/cmake/cmake/-/issues/15687target_include_directories(): SYSTEM option does not seem to work when target...2017-06-27T14:59:10-04:00Kitware Robottarget_include_directories(): SYSTEM option does not seem to work when targeting Xcode.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15687). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15687). Further discussion may take place here.3.8.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/15486CPackRPM - Move Component handling into .spec file2018-12-07T09:57:37-05:00Kitware RobotCPackRPM - Move Component handling into .spec fileThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15486). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15486). Further discussion may take place here.3.8.0https://gitlab.kitware.com/cmake/cmake/-/issues/15432FindHDF5 HDF5_USE_STATIC_LIBRARIES should only apply to HD5 specific libraries2018-12-07T09:57:39-05:00Kitware RobotFindHDF5 HDF5_USE_STATIC_LIBRARIES should only apply to HD5 specific librariesThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15432). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15432). Further discussion may take place here.3.8.0https://gitlab.kitware.com/cmake/cmake/-/issues/14820warn users about removing only CMakeCache.txt2018-12-07T09:58:03-05:00Kitware Robotwarn users about removing only CMakeCache.txtThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14820). Further discussion may take place here.
---
I am trying to build a project which uses cmake and that queries `CMAKE_EXEC...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14820). Further discussion may take place here.
---
I am trying to build a project which uses cmake and that queries `CMAKE_EXECUTABLE_FORMAT`. The project has been building inconsistently for me, and I've tracked that down to `CMAKE_EXECUTABLE_FORMAT` returning an incorrect result after I remove the `CMakeCache.txt` file. (Before removing the cache, it returns a correct value of 'ELF'. After removing the cache, it returns an incorrect value of ''.)
3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/13487CMake can't make kexts2018-12-07T09:58:56-05:00Kitware RobotCMake can't make kextsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13487). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13487). Further discussion may take place here.3.8.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/8996math(EXPR) does not parse unary negation properly2018-12-11T20:23:24-05:00Kitware Robotmath(EXPR) does not parse unary negation properlyThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8996). Further discussion may take place here.
---
```cmake
MATH(EXPR varOutput "-1 + 1")
```
gives an error:
```
CMake...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8996). Further discussion may take place here.
---
```cmake
MATH(EXPR varOutput "-1 + 1")
```
gives an error:
```
CMake Error at CMakeLists.txt:1 (MATH):
math cannot parse the expression: "-1 + 1": syntax error, unexpected
exp_MINUS, expecting exp_OPENPARENT or exp_NUMBER (1)
```
I think `+1 + 1` also does not work.
3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16820VS2017 project references need braces around GUIDs2017-07-12T11:33:23-04:00Richard WaltersVS2017 project references need braces around GUIDsI recently switched from using VS2015 to VS2017, and noticed that project references were being flagged by VS2017 with yellow exclamation point icons, and the properties tab would not show properties for project references:
![example-vs...I recently switched from using VS2015 to VS2017, and noticed that project references were being flagged by VS2017 with yellow exclamation point icons, and the properties tab would not show properties for project references:
![example-vs2017-before](/uploads/6f3cc71c32f3e98870b06f45fec80880/example-vs2017-before.png)
This was not a problem with VS2015:
![example-vs2015](/uploads/00852ae8294e55d3c8c1660c530723d1/example-vs2015.png)
Also, the projects build just fine in either VS2015 or VS2017; the only problem is the problem icons in the GUI and the inability to inspect project reference properties.
I debugged this and discovered that if I put braces around the GUIDs in the project references, the problem would go away:
![example-vs2017-after](/uploads/3899538ebf0eefbadfd9c0e09b8e6b47/example-vs2017-after.png)
I'm not sure if VS2015 was being lenient about accepting the GUIDs without braces, or whether VS2017 is being more strict in requiring them, or if the project file syntax was changed slightly from VS2015 to VS2017.
Before:
` <ItemGroup>
<ProjectReference Include="E:\Workspaces\Lighthouse\build\ZERO_CHECK.vcxproj">
<Project>B031E67B-55D5-31BB-843F-9BB9846A5909</Project>
<Name>ZERO_CHECK</Name>
</ProjectReference>
<ProjectReference Include="E:\Workspaces\Lighthouse\build\ALL_BUILD.vcxproj">
<Project>6C38039E-8969-3EEC-9A17-5EDC7766B4BA</Project>
<Name>ALL_BUILD</Name>
</ProjectReference>
</ItemGroup>
`
After:
` <ItemGroup>
<ProjectReference Include="E:\Workspaces\Lighthouse\build\ZERO_CHECK.vcxproj">
<Project>{B031E67B-55D5-31BB-843F-9BB9846A5909}</Project>
<Name>ZERO_CHECK</Name>
</ProjectReference>
<ProjectReference Include="E:\Workspaces\Lighthouse\build\ALL_BUILD.vcxproj">
<Project>{6C38039E-8969-3EEC-9A17-5EDC7766B4BA}</Project>
<Name>ALL_BUILD</Name>
</ProjectReference>
</ItemGroup>
`3.8.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16816Windows/FindBoost.cmake: Invalid character escape '\L'. (regression? appears ...2017-05-03T10:50:22-04:00Sylwester ArabasWindows/FindBoost.cmake: Invalid character escape '\L'. (regression? appears after upgrading from 3.7.2 to 3.8.0)Here's an error that started popping up in Appveyor builds of a project after CMake was upgraded from 3.7.2 to 3.8.0 (and it seems to me that no other changes could affect the error):
![image](/uploads/aca0437c3000632a2c47868697a70f36...Here's an error that started popping up in Appveyor builds of a project after CMake was upgraded from 3.7.2 to 3.8.0 (and it seems to me that no other changes could affect the error):
![image](/uploads/aca0437c3000632a2c47868697a70f36/image.png)
https://ci.appveyor.com/project/vinecopulib/pyvinecopulib/build/1.0.37/job/vdm2w67623f1gvw93.8.1https://gitlab.kitware.com/cmake/cmake/-/issues/16814Populating the BuildRequires field in a CPack Source RPM2017-04-21T08:56:35-04:00Philip SalvaggioPopulating the BuildRequires field in a CPack Source RPMHello,
I am trying to use CPack to generate a source RPM that I can then rebuild using Mock (https://github.com/rpm-software-management/mock/wiki). My issue is that in order to use Mock, I need to list out all of the build-time dependen...Hello,
I am trying to use CPack to generate a source RPM that I can then rebuild using Mock (https://github.com/rpm-software-management/mock/wiki). My issue is that in order to use Mock, I need to list out all of the build-time dependencies in the BuildRequires field in the .spec file, but I don't see a way in CPack to populate this field. Is this possible at this time? I've been able to hack around it by appending a new line and the field name/value to another one of the RPM attributes, but that isn't a great solution.
Thanks!3.8.1Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16811VS2017 SDK selection during configuration assumes presence of 8.1 SDK2017-04-26T09:03:17-04:00Roger LeighVS2017 SDK selection during configuration assumes presence of 8.1 SDKThere seems to be a problem with VS2017 and the 8.1/10.0 SDKs. Testing configuration of a trivial C++ project with CMake 3.8.0 and an up-to-date VS2017 community desktop installation:
```
D:\test>cmake -G "Visual Studio 15 2017 Win6...There seems to be a problem with VS2017 and the 8.1/10.0 SDKs. Testing configuration of a trivial C++ project with CMake 3.8.0 and an up-to-date VS2017 community desktop installation:
```
D:\test>cmake -G "Visual Studio 15 2017 Win64" h:\code\multiarray
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
CMake Error at CMakeLists.txt:42 (project):
No CMAKE_CXX_COMPILER could be found.
CMake Error at CMakeLists.txt:42 (project):
No CMAKE_C_COMPILER could be found.
-- Configuring incomplete, errors occurred!
```
in the error log:
```
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler:
Build flags:
Id flags:
The output was:
1
Microsoft (R) Build Engine version 15.1.1012.6693
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 16/04/2017 19:50:35.
Project "D:\test\CMakeFiles\3.8.0\CompilerIdCXX\CompilerIdCXX.vcxproj" on node 1 (default targets).
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\x64\PlatformToolsets\v141\Toolset.targets(36,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [D:\test\CMakeFiles\3.8.0\CompilerIdCXX\CompilerIdCXX.vcxproj]
Done Building Project "D:\test\CMakeFiles\3.8.0\CompilerIdCXX\CompilerIdCXX.vcxproj" (default targets) -- FAILED.
```
I have the `10.0.15063.0` SDK installed (the current 2017 default). I don't have the `8.1` SDK installed.
I'm unsure why the CMake check here is specifically requiring the 8.1 SDK, rather than using the default one which was installed by the VS2017 installer. I have not made any specific selection of an SDK here, so my expectation would be that CMake would not have enforced the assumption that 8.1 was required, when there's another viable SDK to choose from. That said, my understanding of the byzantine world of Windows may well not be complete either, and I may have missed some subtle complication.
Kind regards,
Roger3.8.1Roger LeighRoger Leighhttps://gitlab.kitware.com/cmake/cmake/-/issues/17076ninja: generated resources are regenerated on clean if not present2017-07-20T07:11:34-04:00Norbert Pfeilerninja: generated resources are regenerated on clean if not presentWhen the generated file is present `clean` runs through smoothly, apart from weird ninja warnings:
>ninja: warning: multiple rules generate foo.qrc. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
...When the generated file is present `clean` runs through smoothly, apart from weird ninja warnings:
>ninja: warning: multiple rules generate foo.qrc. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
(reported [here](https://github.com/ninja-build/ninja/issues/1298))
But if the file wasn’t generated yet or `ninja clean` (`cmake --build . --target clean` doesn’t exhibit this) is run consecutively, the file is generated and CMake is rerun to regenerate the build files before actually cleaning.
```
project(cmake-ninja-generated-autogen-clean)
cmake_minimum_required(VERSION 3.0.0 FATAL_ERROR)
set(CMAKE_AUTORCC ON)
find_package(Qt5 REQUIRED COMPONENTS Core)
add_custom_command(OUTPUT foo.qrc
COMMAND ${CMAKE_COMMAND} -E touch foo.qrc
COMMAND echo "oh noes"
)
add_executable(${PROJECT_NAME} foo.qrc)
set_property(TARGET ${PROJECT_NAME} APPEND PROPERTY AUTOGEN_TARGET_DEPENDS foo.qrc)
```3.9.0https://gitlab.kitware.com/cmake/cmake/-/issues/17059Android: Passing sysroot /usr/include to include_directories breaks ordering2017-07-13T10:07:38-04:00Brad KingAndroid: Passing sysroot /usr/include to include_directories breaks orderingWhen cross-compiling to Android, the code
```cmake
include_directories(${CMAKE_SYSROOT_COMPILE}/usr/include)
```
causes the `-isystem /path/to/sysroot/usr/include` argument that CMake adds to move too early in the command line. This d...When cross-compiling to Android, the code
```cmake
include_directories(${CMAKE_SYSROOT_COMPILE}/usr/include)
```
causes the `-isystem /path/to/sysroot/usr/include` argument that CMake adds to move too early in the command line. This directory is listed in `CMAKE_${lang}_STANDARD_INCLUDE_DIRECTORIES` and therefore should be added only at the end of the command line. It should be filtered out of user-specified directories because it is an implicit include directory.
This was discovered by discussion in [Android NDK issue 452](https://github.com/android-ndk/ndk/issues/452).3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17052Potential find_library() issue in CMake 3.9rc52017-07-12T08:59:10-04:00Luis Caro CamposPotential find_library() issue in CMake 3.9rc5CMake 3.9rc5, on Windows x64, using the VC14 generator.
I'm using a variant of this module to find TBB: https://github.com/cmake-basis/find-modules/blob/master/FindTBB.cmake
The module as described in its header section uses 'TBB_ROOT'...CMake 3.9rc5, on Windows x64, using the VC14 generator.
I'm using a variant of this module to find TBB: https://github.com/cmake-basis/find-modules/blob/master/FindTBB.cmake
The module as described in its header section uses 'TBB_ROOT' as a hint. I am defining TBB_ROOT to point to the correct directory before calling find_package(TBB).
With the TBB_DEBUG enabled, flag, it prints this out correctly:
```
** FindTBB: Initial search paths:
** FindTBB: - Root directory hints = [C:/path/to/tbb/4.4.5]
** FindTBB: - Include path suffixes = [include]
** FindTBB: - Library path suffixes = [lib;lib/intel64/vc14]
```
The libraries in question are indeed in the "lib/intel64/vc14" directory relative to TBB_ROOT.
However, on CMake 3.9rc5 the call to find_library fails and the libraries are not found.
I've found that if I add `NO_PACKAGE_ROOT_PATH` to the following call, it works correctly.
```
find_library(TBB_${_TBB_COMPONENT}_LIBRARY_RELEASE
NAMES ${_TBB_${_TBB_COMPONENT}_LIB_NAMES_RELEASE}
HINTS ${TBB_ROOT}
PATH_SUFFIXES ${_TBB_LIB_PATH_SUFFIXES}
)
```
My question is, what wouldn't it work without that flag anyway? From the 3.9rc5 `find_library` documentation:
> If called from within a find module, search prefix paths unique to the current package being found. Specifically look in the PackageName_ROOT CMake and environment variables. The package root variables are maintained as a stack so if called from nested find modules, root paths from the parent’s find module will be searchd after paths from the current module, i.e. CurrentPackage_ROOT, ENV{CurrentPackage_ROOT}, ParentPackage_ROOT, ENV{ParentPacakge_ROOT}, etc. This can be skipped if NO_PACKAGE_ROOT_PATH is passed.
Am I experiencing a 'bad' interaction between TBB_ROOT being set, and find_library being called *without* `NO_DEFAULT_PATH` first? Is the "HINTS" how relative to TBB_ROOT and that's why it isn't working? Or should it be "PATHS" instead of "HINTS"?
I'm just concerned about potential problems with existing modules.3.9.0Brad KingBrad King