I have a custom toolchain for building projects. And by custom toolchain, I mean a derivative of the Clang C compiler, C++ compiler, and linker.
The project(s) build just fine, but I'm unable to use the Intellij features of CLion, because it can't build a tags database (or whatever it does under the hood) due to not being able to recognize the custom toolchain.
Thus, hitting Tools -> CMake -> Reset Cache and Reload Project spits out:
/Applications/CLion.app/Contents/bin/cmake/mac/bin/cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=~/<path-to-custom-toolchain>/Toolchain.cmake -G "CodeBlocks - Unix Makefiles" /Users/<project-directory>/src
-- Setting up Toolchain 1.0 at /Users/<tools>/build
-- Setting up Toolchain 1.0 at /Users/<tools>/build
-- The C compiler identification is Clang 7.0.0
-- The CXX compiler identification is Clang 7.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting C compile features
-- Detecting C compile features - failed
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Detecting CXX compile features
-- Detecting CXX compile features - failed
-- Configuring done
Screenshot of the preference options for the project (It's a link because I don't have the rep required to post images yet):
Project Preferences
So my question is, how should I go about solving this problem? Or does this problem exceed the limitations of CLion? Or do I have an incomplete understanding of the problem?
Related
I trying compile NGP but after cmake . -B build I get this lines:
I've installed
Visual Studio 2019
CUDA Toolkit 11.6
CMake 3.22
Python 3.10
Optix 7.6
C:\NGP\instant-ngp>cmake . -B build
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
-- The C compiler identification is MSVC 19.29.30147.0
-- The CXX compiler identification is MSVC 19.29.30147.0
-- The CUDA compiler identification is NVIDIA 11.6.124
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting CUDA compiler ABI info
-- Detecting CUDA compiler ABI info - done
-- Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.6/bin/nvcc.exe - skipped
-- Detecting CUDA compile features
-- Detecting CUDA compile features - done
-- **Obtained CUDA architectures automatically from installed GPUs**
**CMake Error: The source directory "SOURCES/CMakeFiles/CMakeTmp" does not exist.**
Specify --help for usage, or press the help button on the CMake GUI.
CMake Error at dependencies/tiny-cuda-nn/CMakeLists.txt:107 (try_run):
Failed to configure test project build system.
Call Stack (most recent call first):
dependencies/tiny-cuda-nn/CMakeLists.txt:146 (TCNN_AUTODETECT_CUDA_ARCHITECTURES)
-- Configuring incomplete, errors occurred!
See also "C:/NGP/instant-ngp/build/CMakeFiles/CMakeOutput.log".
I am not coder I just want to try NERF. It ss possible download somewhere compiled NGP or it doesn't work that way?
EDIT: Noticed that OP is using the -S flag implicitly the issue seems to be elsewhere, hence the updated answer:
UPDATED ANSWER
Please bare in mind that with the limited information at my disposal. This is again only a wild guess, based on what I tried.
After re-examining the output of CMake I've noticed that the issue is within one of the dependencies i.e.
CMake Error at dependencies/tiny-cuda-nn/CMakeLists.txt:107 (try_run):
I was not able to completely replicate the problem, however I do believe I know how to debug these issues. My wild guess here is that either:
The individual dependencies were incorrectly pulled or
The CMake files were poorly generated due to some issue and you didn't clean them.
I would recommend trying the following:
Delete the build folder, and run cmake -S. -Bbuild again. And if that fails you can try the second option.
Remove the git repository (folder called instant-ngp) and clone it again using exactly this command:
git clone --recursive https://github.com/nvlabs/instant-ngp
Please note that the --recursive option is very important due to the fact that you need to pull the dependant repositories as well.
Now if all of that fails. You still have one more option and that is to go to the folder dependencies/tiny-cuda-nn/ and generate the CMake files yourself, however I do not recommend that due to the fact that if you have limited experience you may not know what exactly to do.
I've also checked the variables you wanted to set, and you may do that by running this in Powershell
$Env:CMAKE_CUDA_ARCHITECTURES=YOUR_VALUE_HERE (in my case it is 75 because I have a RTX2080). However bare in mind that
You shouldn't need it, because the architecture is discovered for you
You need to delete the build folder in order to clean up the cached CMake files
Hope it helps!
Goal
I am using CMake to make the build for my project which is an embedded firmware based on ARM Cortex platform built using arm-none-eabi-gcc-6.3.1 compiler, using VSCode Editor, and on Windows host. I am trying to make a second build for testing on the Windows system I am using for the same project.
The First Solution Problem
The issue I am having is that whenever I need to switch my build from production to test, I have to delete the build files and rerun the CMake command with the test argument, when I do not do that, the build does not change the ARM compiler to the one I intend to use (I am guessing it is a caching problem). I have tried make clean and make rebuild_cache thinking that it may clean the cache and solve the problem for me, and did not work.
A fresh build Example:
Project\build> cmake -G"MinGW Makefiles" -DTARGET_GROUP=test ..
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= C:/MinGW/bin/gcc.exe
CMAKE_CXX_COMPILER= C:/MinGW/bin/g++.exe
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/MinGW/bin/gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: Path\to\Project\build
Project\build>make
(successful make)
The second build:
Project\build> cmake -G"MinGW Makefiles" -DTARGET_GROUP=production ..
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= Path/to/arm-gnu-toolchain/bin/arm-none-eabi-gcc.exe
CMAKE_CXX_COMPILER= Path/to/arm-gnu-toolchain/bin/arm-none-eabi-g++.exe
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/MinGW/bin/gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: Path\to\Project\build
Project\build>make
(Cached make -did not change the compiler or the files to be built)
The CMakeLists.txt:
set(TARGET_GROUP test CACHE STRING "Group to build")
if(TARGET_GROUP STREQUAL production)
# ARM Lib
include("arm-gnu.cmake")
else()
include("win-gcc-for-testing.cmake")
endif()
# include the files based on the TARGET_GROUP value
# ...
Current Solution
Currently, I have a temporary solution by making a separate folder for each building type and they work perfectly.
The question
Is the current solution (making two build directories each is for a different environment) right in terms of best practices? If not, what could be a better one?
As #Tsyvarev says, you have to use different directories if you want different builds. Here you are trying to build both in the same build directory. Instead, create a subdirectory test to build the -DTARGET_GROUP=test, and a different subdirectory prod to build the -DTARGET_GROUP=production:
Project> mkdir test
Project> cd test
Project\test> cmake -G"MinGW Makefiles" -DTARGET_GROUP=test ..
Project\test> cd ..
Project> mkdir prod
Project> cd prod
Project\prod> cmake -G"MinGW Makefiles" -DTARGET_GROUP=production ..
Of course you can call the directories whatever you like.
Since you'd like this to integrate into VSCode, do the configuration change with the CMake build kits, which is what sets the compiler prior to calling CMake. You can specify additional user kit definitions, and in the VSCode interface choose between compiler kits.
Rewrite the CMake files just enough to condition everything else on the selection of compiler.
THEN, the VSCode cmake-tools extension supports variable expansion for the name of the build directory. Among the options are ${buildKit} and ${buildKitTargetArch}. Make this suffix part of the Build Directory setting (your choice of whether to set this only in your workspace, or more globally on your system).
Now, when you switch kits, CMake will pick up the directory change and happily exist with two different build directories.
Alternatively, cmake-tools now provides variants, which could be used to add additional Production and Test to the normal Release, Debug, RelWithDebInfo, etc. There are additional build directory expansion variables for information from the currently selected variant.
I found someone mentioned to use such command line to use cmake with vs2019 and llvm toolset:
cmake -G "Visual Studio 2019" -T ClangCL
However, this would use the llvm version, which is 11.0 for now, was installed by the visual studio instanller.
I want to use a new version, thus 12.0, of llvm which I already installed somewhere else but I don't know how to make cmake and vs to use that.
UPDATE:
What I tried to set the compiler via command line:
E:\my_proj>cmake -G "Visual Studio 16 2019" -A x64 -T "ClangCL" -DCMAKE_C_COMPILER="C:\Program Files\LLVM\bin\clang.exe" -DCMAKE_CXX_COMPILER="C:\Program Files\LLVM\bin\clang++.exe" .
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.19042.
-- The C compiler identification is Clang 11.0.0 with MSVC-like command-line
-- The CXX compiler identification is Clang 11.0.0 with MSVC-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
As you could see the cmake picked the clang from the vs installed location and ignored the command line.
As described below, setting CMAKE flags explicitly has no effect when using VS generator. Thus choosing the default compiler installed by Visual Studio installer.
The VS generator produces .vcxproj files and uses MSBuild to actually
drive the build. The values of CMAKE_{C,CXX}_COMPILER are computed
automatically from the compiler MSBuild chooses so setting them has no
effect.
Recently I've started using cmake instead of creating make-files manually. Moreover I use kdevelop as an IDE. So, I created simple cmake project with kdevelop. It builds and executes successfully. But the thing is that when I try to run cmake from terminal (without kdevelop involved in the process) I see that cmake just loads the cpu as high as possible and there is no result for about half an hour. I couldn't wait more so I've just kill the process.
Here is my cmake file:
project(robot)
cmake_minimum_required(VERSION 2.8)
set(CMAKE_BUILD_TYPE Debug)
include_directories(include)
add_library(mylib SHARED mylibsrc/mylib.cpp)
Here is how kdevelop starts runs cmake:
/home/sergey/projects/project-test/build> /usr/bin/cmake -DCMAKE_BUILD_TYPE=Debug /home/sergey/projects/project-test/
-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /home/sergey/bin/gcc
-- Check for working C compiler: /home/sergey/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/sergey/bin/c++
-- Check for working CXX compiler: /home/sergey/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/sergey/projects/project-test/build
I try to run cmake in same way but all I receive is the highest possible cpu load.
kdevelop version - 4.8.4
cmake version - 2.8.9
Can you advice anything about that?
Sorry for my broken English.
You can try adding the --trace option to the cmake call. The problem will still exist, but at least you should see then what is taking so long and can then further investigate. The --debug-output option might also help.
/usr/bin/cmake -DCMAKE_BUILD_TYPE=Debug --trace --debug-output /home/sergey/projects/project-test/
I try to build oglplus (C++ wrapper for OpenGL) with cmake (on OS X 10.9 with Xcode 5 / Clang 5.0.0).
But to do so, there is a context initialization library neccesary (i.e. GLUT, GLFW, GLFW3, GL3W, QT4, SDL, wxWidgets). However I tried to compile and install GLFW and GLFW3 multiple times already: But the cmake file from oglplus still won't use them.
The cmake output says:
cmake -G Xcode
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler using: Xcode
-- Check for working C compiler using: Xcode -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Xcode
-- Check for working CXX compiler using: Xcode -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
-- Found GLEW: /usr/local/include /Library/Frameworks/GLEW.framework
-- Could NOT find GL3W
-- Could NOT compile or link with GLFW
-- Could NOT compile or link with GLFW3
-- Could NOT find GLUT (missing: GLUT_INCLUDE_DIR)
-- GLUT header file not found
-- Could NOT find wxWidgets (missing: wxWidgets_FOUND)
-- Could NOT find Qt4 (missing: QT_QMAKE_EXECUTABLE QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE QT_INCLUDE_DIR QT_LIBRARY_DIR QT_QTCORE_INCLUDE_DIR QT_QTCORE_LIBRARY QT_QTGUI_INCLUDE_DIR QT_QTGUI_LIBRARY QT_QTOPENGL_INCLUDE_DIR QT_QTOPENGL_LIBRARY QT_UIC_EXECUTABLE)
-- Could NOT find SDL
-- GLM header files not found
-- Found PNG: /usr/local/include /usr/local/lib/libpng.dylib
-- Detecting support for c++11 feature 'SCOPED_ENUMS': TRUE
-- Detecting support for c++11 feature 'VARIADIC_MACROS': TRUE
-- Detecting support for c++11 feature 'VARIADIC_TEMPLATES': TRUE
-- Detecting support for c++11 feature 'UNIFIED_INITIALIZATION_SYNTAX': TRUE
-- Detecting support for c++11 feature 'INITIALIZER_LISTS': TRUE
-- Detecting support for c++11 feature 'DEFAULTED_FUNCTIONS': TRUE
-- Detecting support for c++11 feature 'DELETED_FUNCTIONS': TRUE
-- Detecting support for c++11 feature 'EXPLICIT_CONVERSION_OPERATORS': TRUE
-- Detecting support for c++11 feature 'FUNCTION_TEMPLATE_DEFAULT_ARGS': TRUE
-- Detecting support for c++11 feature 'UNICODE_LITERALS': TRUE
-- Detecting support for c++11 feature 'USER_DEFINED_LITERALS': TRUE
-- Detecting support for c++11 feature 'CONSTEXPR': TRUE
-- Detecting support for c++11 feature 'NOEXCEPT': TRUE
-- Detecting support for c++11 feature 'LAMBDAS': TRUE
-- Detecting support for c++11 feature 'NULLPTR': TRUE
-- Detecting support for c++11 feature 'CHRONO': TRUE
-- Detecting support for c++11 feature 'THREADS': TRUE
-- Could NOT find Boost
CMake Error at CMakeLists.txt:122 (message):
No OpenGL context initialization library found!
So it seems it can find GLFW/GLFW3, because for some reason it says Could NOT compile or link with * instead of Could NOT find *. I'm not really familiar with cmake scripts, so I don't know how to examine the reason here.
Any ideas what the problem could be here?
I've had a similar problem, it seems that GLFW is found and a test program is compiled to check that it works. Simply put, with the MSVC toolchain the test fails.
The simplest fix is to remove/rename the test program (oglplus/config/ext_lib/test_glfw.cpp and/or test_glfw3.cpp)
Have you read the documentation on GitHub? Direct extract:
CMake-based build configuration
The CMake script defines and uses several variables to modify the
build configuration, which can be specified on the command-line when
invoking cmake (with the -D option. see cmake manual for details):
HEADER_SEARCH_PATHS: (semicolon-separated) list of paths to additional directories to search when looking for 3rd-party headers like GL/glew.h, GL3/gl3.h, GL/glcorearb.h, etc.
LIBRARY_SEARCH_PATHS: (semicolon-separated) list of paths to additional directories to search when looking for 3rd-party binary libraries like GL, GLEW, GL3W, GLFW, SDL, GLUT, png, etc.
Furthermore, OGLplus is, in fact, a header-only library, so you could simply skip building examples/demos and tests so that no linkage with 3rd party libraries is required at all. You could even copy the headers to the location you want and just use it without running CMake (last time I used it, this approach worked fine, it might have changed, so check it at your own risk).
I know this is an old question, but I also had problems with it.
Just make sure that you specify the include- and lib-folders for glfw, glfw3 or whatever you want to use in cmake.