Моя ОС - centos, которая имеет gcc по умолчанию /usr/bin/gcc. Но он старый, мне нужна новая версия gcc. Поэтому я устанавливаю новую версию в новый путь /usr/local/bin/gcc.
Но когда я запускаю cmake, он по-прежнему использует путь gcc старой версии (/usr/bin/gcc). Как указать gcc на новый путь (/usr/local/bin/gcc).
Я попытался перезаписать /usr/bin/gcc с помощью /usr/local/bin/gcc, но он не работает.
Не перезаписывайте CMAKE_C_COMPILER, а экспортируйте CC (и CXX) перед вызовом cmake:
export CC=/usr/local/bin/gcc
export CXX=/usr/local/bin/g++
cmake /path/to/your/project
make
Экспорт нужно выполнить только один раз, при первом запуске проекта эти значения будут считаны из кэша cmake.
ОБНОВЛЕНИЕ: более подробное объяснение того, почему не переопределять CMAKE_C(XX)_COMPILER после комментария Джейка
Я рекомендую не переопределять значение CMAKE_C(XX)_COMPILER по двум основным причинам: потому что он не будет хорошо работать с кэшем CMake и потому, что он прерывает проверку компилятора и обнаружение инструментов.
При использовании команды set у вас есть три варианта: без кеша, создать обычную переменную с кешем для создания кешированной переменной и принудительного кэша, чтобы всегда принудительно вводить значение кеша при настройке.
Посмотрим, что произойдет для трех возможных вызовов set:
Без кеша
set(CMAKE_C_COMPILER /usr/bin/clang)
set(CMAKE_CXX_COMPILER /usr/bin/clang++)
При этом вы создаете "нормальную" переменную CMAKE_C(XX)_COMPILER, которая скрывает переменную кеша с тем же именем. Это означает, что ваш компилятор теперь жестко закодирован в вашей сборке script, и вы не можете дать ему пользовательское значение. Это будет проблемой, если у вас несколько условий сборки с разными компиляторами. Вы можете просто обновить свой script каждый раз, когда хотите использовать другой компилятор, но в первую очередь удаляет значение использования CMake.
Хорошо, тогда обновите кеш...
С кешем
set(CMAKE_C_COMPILER /usr/bin/clang CACHE PATH "")
set(CMAKE_CXX_COMPILER /usr/bin/clang++ CACHE PATH "")
Эта версия просто "не работает". Переменная CMAKE_C(XX)_COMPILER уже находится в кеше, поэтому она не будет обновляться, если вы ее не нажмете.
А... давайте использовать силу, затем...
Силовой кэш
set(CMAKE_C_COMPILER /usr/bin/clang CACHE PATH "" FORCE)
set(CMAKE_CXX_COMPILER /usr/bin/clang++ CACHE PATH "" FORCE)
Это почти то же самое, что и "нормальная" версия переменной, единственное отличие заключается в том, что ваше значение будет установлено в кеше, чтобы пользователи могли его видеть. Но любое изменение будет перезаписано командой set.
Нарушение проверок и инструментов компилятора
В начале процесса настройки CMake делает проверки на компиляторе: это работает? он способен создавать исполняемые файлы? и т.д. Он также использует компилятор для обнаружения связанных инструментов, таких как ar и ranlib. Когда вы переопределяете значение компилятора в script, оно "слишком поздно", все проверки и обнаружения уже выполнены.
Например, на моей машине с gcc как компилятором по умолчанию, при использовании команды set до /usr/bin/clang, ar устанавливается на /usr/bin/gcc-ar-7. При использовании экспорта перед запуском CMake устанавливается значение /usr/lib/llvm-3.8/bin/llvm-ar.
Установите CMAKE_C_COMPILER на новый путь.
Смотрите здесь: http://www.cmake.org/Wiki/CMake_Useful_Variables
Экспортировать должен быть конкретный вопрос о том, какую версию GCC/g++ использовать, потому что если у пользователя была несколько версий компилятора, она не будет скомпилирована успешно.
export CC=path_of_gcc/gcc-version
export CXX=path_of_g++/g++-version
cmake path_of_project_contain_CMakeList.txt
make
В случае использования проекта С++ 11 это можно обработать с помощью флага -std=C++-11 в CMakeList.txt
Альтернативным решением является настройка вашего проекта через cmake-gui, начиная с чистого каталога сборки. Среди опций, которые у вас есть в начале, есть возможность выбрать точный путь к компиляторам