I am working with a very inconvenient software, and it doesn't support clang. So, I am required to change my cmake compiler and as I read almost everywhere, and here How can I make CMake use GCC instead of Clang on Mac OS X?, I tried :
cmake -DCMAKE_CXX_COMPILER=/usr/bin/g++
However, I am still getting this error
CMake Error at CMakeLists.txt:59 (message):
GAMBIT does not support the Clang compiler. Please choose another
compiler.
-- Configuring incomplete, errors occurred!
Any suggestion, please?
I've found setting environment variables CC and CXX before running CMake for the first time peferrable to messing with CMAKE_CXX_COMPILER. Also note that it's probably a good idea to set both. So get into an empty binary directory and run this:
CC=/usr/bin/gcc CXX=/usr/bin/g++ cmake ...
Also make sure that /usr/bin/gcc is really GCC and not e.g. a symlinked or otherwise disguised Clang (I believe such setup can exist in the MacOS world).
You probably need to set CMAKE_C_COMPILER as well, that is:
cmake -DCMAKE_CXX_COMPILER=/usr/bin/g++ -DCMAKE_C_COMPILER=/usr/bin/gcc
Indeed, looking at Gambit source code, it seems it's mostly C.
Personally, I usually like to set both, just in case.
Related
This is probably not possible, but I still want to ask. I'm using Clangd as an autocompletion engine for VSCode. It works great, but there is one problem.
The official Windows binaries of Clang rely on MSVC standard library headers. If MSVC is not installed, Clang and Clangd complain about missing headers.
There's a flag that makes Clang use MinGW's libstdc++ (--target=x86_64-w64-windows-gnu), which I have to include in compile_commands.json.
This solution works, but it would be nice to have sensible autocomplete even without compile_commands.json.
Is there a way I can tell Clangd to assume --target=x86_64-w64-windows-gnu if there is no compile_commands.json?
At some point after the question was asked, the VSCode Clangd extension started exposing the default flags to the config: "clangd.fallbackFlags": ["--target=x86_64-w64-windows-gnu"].
Is there a way I can tell Clangd to assume --target=x86_64-w64-windows-gnu if there is no compile_commands.json?
From clangd getting started:
compile_flags.txt
If all files in a project use the same build flags, you can put those
flags one-per-line in compile_flags.txt in your source root.
Clangd will assume the compile command is clang $FLAGS some_file.cc.
Creating this file by hand is a reasonable place to start if your
project is quite simple.
Just create compile_flags.txt file with --target=x86_64-w64-windows-gnu.
We work with a specific compiler, which is called Cadul. It has its own libraries, targets etc. The problem is that CMake does not support it in contrast to such "standard" compilers as GNU, Intel, Clang etc.
Firstly I thought to use cross compiling but it didn't work, since the host and target platforms are the same.
Then I looked into Modules, where I found the directory named "Compiler" which contains a lot of ".cmake" files specified for each compiler and each enabled language. I tried to substitute the word "GNU" by "Cadul" and hoped to see any changes, such as "The CXX compiler identification is Cadul ...". But it didn't happen.
Then I just removed the whole directory "Modules" from cmake and hoped to see that it doesn't work anymore. Surprisingly it did.
So has anyone ever integrated a new compiler to Cmake? With its own features, etc.
It looks like this has been recommended in the comments, but no one has condensed it to an answer yet.
You can choose a compiler by adding these lines to your CMakeLists.txt (source):
SET(CMAKE_C_COMPILER /path/to/c/compiler)
SET(CMAKE_CXX_COMPILER /path/to/cpp/compiler)
If you need to customize further, using a toolchain file works well. There are some examples in the documentation here.
Yes, I've done this before. But you need a lot more then just setting the compiler path (since CMake would try to identify this compiler and then - since it's unknown to CMake - would throw an error).
An example implementation of a new "compiler" can be found in my answer here:
Generic rule from makefile to cmake
It shows a enable_language(FOO) example that could be replaced with enable_language(Cadul).
I am building an open source project (kst, v2.0.8) that uses CMake. I am using CMake v2.8.12.2 and MSVC 2008 as a compiler and am generating NMake makefiles to build it on the command line. I can get it to build successfully with this setup. These versions are mandated so I cannot currently use a later version of CMake or MSVC.
I need to be able to perform a source code analysis of kst using HP's Fortify and to be able to use it from the command line it works in one of two ways:
Touchless mode where it creates it's own "cl.exe", sets the path to it before the path to the real cl.exe and therefore gets launched during build.
Set the compiler in the makefile to the Fortify command line, e.g. sourceanalyzer -b build_id cl instead of cl.
Either way I need to force the compiler that cmake generates into its makefiles to be something that cmake does not automatically detect.
I've tried setting the compiler when running cmake following the same method in this question but cmake still insists on putting the full path to the MSVC cl.exe in the makefiles.
cmake -DCMAKE_C_COMPILER=cl -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER=cl -DCMAKE_CXX_COMPILER_FORCED=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR% -G"NMake Makefiles" ..\cfit3250
I also tried setting the compiler to invoke Fortify but when cmake tests the compiler it fails saying that it cannot find the compiler. (I have also tried this without the FORCED=ON arguments and in that case it says the compiler fails.)
cmake -DCMAKE_C_COMPILER="sourceanalyzer -b %BUILDID% cl" -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER="sourceanalyzer -b %BUILDID% cl" -DCMAKE_CXX_COMPILER_FORCED=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR% -G"NMake Makefiles" ..\cfit3250
I could probably search and replace all the compiler invocations in the makefiles but I'd have to remember to do that after every cmake, and it would be tedious seeing as there are multiple projects / makefiles / calls to cl (rather than defining a CC variable in the makefile). I'd rather have a way to make cmake use the desired compiler right from the offset.
UPDATED: Testing showed the original suggested approach didn't work as expected on at least some platforms. It seems using a wrapper script is likely the way to go.
If you really want to force a particular compiler and by-pass CMake's compiler checks, the CMakeForceCompiler module may be what you are looking for. That link to the CMake docs contains a trivial toolchain file example which shows how to use a specific compiler invoked as a simple command with no path. Unfortunately, CMake still converts this to an absolute path, so on its own, this won't solve your problem. You could, however, use a toolchain file to point at a wrapper script and use CMakeForceCompiler to bypass the compiler checks. This combination should yield the behaviour you've asked for, but note that CMakeForceCompiler is now deprecated.
Note that when using the CMakeForceCompiler module, you take on a bit more responsibility for telling CMake information, notably the compiler ID of the particular compiler you want to force using, but from the CMake docs it seems pretty clear this will just be MSVC in your case.
To use a toolchain file, invoke CMake with a -DCMAKE_TOOLCHAIN_FILE=path/to/file option pointing at your own custom toolchain file. The CMake docs have a specific section covering the use of toolchains, although it does gloss over some of the important nitty gritty details.
As mentioned in #Tsyvarev's comment, the use of a wrapper script is likely to be your best way of dealing with this. That wrapper script just needs to forward the call to the usual compiler command without specifying a path. You then take responsibility for ensuring the command will be on your PATH when you do a build. Something as simple as the following should suffice as a wrapper batch file on Windows (untested):
cl %*
Now, you can control whether the Visual Studio compiler or Fortify gets invoked purely by the PATH the build sees. Personally, I think this is a bit fragile, but it's what you asked for. ;)
As a more robust alternative, is it possible to use two completely separate builds? If so, then I'd recommend that as a better alternative. Build one with the default Visual Studio compiler as normal and for the other build, use a toolchain file to point at the Fortify compiler to get CMake to bypass its compiler checks. That way you aren't relying on the build environment being set up a particular way.
I keep getting this error message while trying to Make this Azteroids project: "c++: error: unrecognized command line option ‘-stdlib=libc++’"
Based on what I've seen online, people are saying it's a Clang flag and the C++11 flag looks different. I mean, I don't disagree, but the instructions for creating the Azteroids executable are pretty simple and CMake seems to recognize C++11 support.
Is this a shortcoming of the cmake system in this project or am I missing a dependency or step? I don't understand. And yes, I've seen the similar questions.
Please see this Pastebin for more both the CMake and Make output.
Nothing in that output indicates that clang is involved here at all. Which is likely the problem.
It would seem that -stdlib=libc++ is a clang flag that your GNU c++ binary does not understand. Those flags are being manually added by the cmake configuration of that project. Which means it will not work without clang. So either remove those flags or install clang and configure cmake to use it.
I would like to use the Intel compiler icc (or icpc) with a CMake-based project (on Linux for what it's worth). I can of course export the CXX variable when calling cmake, e.g. like
CXX=icpc cmake ../
and this works fine. I would however like to make this choice available via a custom option. For this I parse custom option, e.g.
cmake -DMY_COMPILER_OPTION=Intel ..
as
IF (MY_COMPILER_OPTION STREQUAL "Intel")
MESSAGE(STATUS "** Compiling with Intel settings **")
SET(CMAKE_CXX_COMPILER "icpc")
SET(CMAKE_CXX_FLAGS_RELEASE "-O3 -w")
SET(CMAKE_CXX_FLAGS_DEBUG "-g")
ENDIF ()
and set CMAKE_CXX_COMPILER together with some compiler flags. This also works, however there is an important "but".
I would also like to use the option -ipo (interprocedural optimization) for my code when compiling with icc plus I need to compile a static library within the build process. For this to work, I need to use Intel's xiar (and also xilink I guess).
cmake actually offers a special property for this
set_property(TARGET mytarget PROPERTY INTERPROCEDURAL_OPTIMIZATION 1)
however this only seems to works properly when the compiler has been set via the environment variable (then xiar is used). When setting the compiler via CMAKE_CXX_COMPILERthis property is ignored.
Is there another way to do this?. Some recommended way? Or at least a work-around?
The recommended way is to run cmake with the appropriate CMAKE_<LANG>_COMPILER defined.
Linux users
cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort ..
Windows users
From an Intel Compiler console:
cmake -G "NMake Makefiles" -DCMAKE_C_COMPILER=icl -DCMAKE_CXX_COMPILER=icl -DCMAKE_Fortran_COMPILER=ifort ..
Ok, since there have been no answers here, I've also turned to the CMake mailing list list for help on this issue. The consent of the experts there seems to be that the way I was trying to do this is a rather bad idea. The reason is that the parsing of my custom flags happens to late in the initialization process. One should therefore rely on setting the compiler via environment variables and let CMake do its magic during the initial configuration run. I will modify my approach..
Basically, avoid trying to change the compiler. See the FAQ: How do I use a different compiler?. CMake Toolchain files provide a way to support some complex cases, like an exotic HPC compiler.