Open rijobro opened 4 years ago
Likely related: #1370.
We are experiencing similar (or equivalent issues). Our use case is to prebuild our repository outside of VSCode for cloud-based codespaces. However, as soon as VSCode with our settings is opened it seems to clear the build folder or at least some cache variables since a complete reconfigure is triggered and targets are invalidated in the sense that when you try to build them, everything needs to be built again. I lost track of which combinations of the following variables we tried, together with the choice of "Unspecified" Kit or a pre-defined Kit (of course matching the compilers used for the prebuild):
"cmake.clearOutputBeforeBuild": false,
"cmake.ignoreKitEnv": true,
"cmake.configureOnOpen": false,
"cmake.skipConfigureIfCachePresent": true,
There is one more possible cause for the unwanted configure. Similar to configureOnOpen, there is also configureOnEdit which has effect when editing the CMakeLists.txt or changing cmake.sourceDirectory setting. Do you happen to do any of this?
Increase the logging verbosity with "cmake.loggingLevel": "Debug" in your .vscode/settings.json, reload the project (and do any operations that usually trigger this to happen) and share with us the content of the "CMake/Build" output channel.
I also suffer for the same problem. My CMake includes another (header-only) CMake project with
add_subdirectory ("path/to/subproject")
I also suffer for the same problem. My CMake includes another (header-only) CMake project with
add_subdirectory ("path/to/subproject")
Mine was in facts related with #997. I had to leave the toolkit unspecified, because my own CMakeLists was forcing a particular version of GCC. Anyway that was bringing me here to the same error.
Hi, any update on this?
I ran into this same issue, only I was using g++. I saw the problem when both the first and second cmakes occurred in vscode. Since I knew things worked outside vscode, I tried running vscode’s cmake command instead of my cmake command, and I got the same error. So this issue can be reproduced with cmake directly, without vscode. I’ve found that this is a known cmake issue, but vscode pushes the user down that path. The cmake issue is that it forgets command line defines when it’s doing its reset. The critical difference between the command I use for cmake directly and the command vscode generates is vscode specifies CMAKE_C_COMPILER and CMAKE_CXX_COMPILER. When I don’t specify the compiler, cmake uses the ones in /usr/bin/. vscode is using the ones in /bin/. The path shouldn’t matter since the binaries are the same, but the difference makes cmake unhappy. I can’t see how to get vscode to exclude these arguments or give different paths. The core problem started when I created the project. vscode asked if I wanted GCC using the compiles in /bin/, and I said yes. The ones in /usr/bin/ weren’t an option. I needed to answer Unspecified so that cmake figures it out on its own. This solved my problem. I just wish I knew how to undo that compiler selection without deleting all my vscode settings.
Brief Issue Summary
I run cmake externally and successfully set all variables, configure and build the project. I then open VSCode, and cached variables get reset, causing the cmake to fail. I then open the CMake project externally, and the cached variables has been deleted there, too.
It seems that VSCode isn't properly parsing the CMakeCache.txt. Since I've correctly configured the build repository prior to running VSCode, it should just need to run the CMake, and shouldn't need to modify any variables.
Expected:
make install
Apparent Behavior:
make install
CMake Tools Log
Developer Tools Log
Platform and Versions
Screenshots
Project configured externally.
STIR_DIR
correctly setOpen VSCode,
STIR_DIR
not foundRe-open CMake externally,
STIR_DIR
has been reset