Создать системную переменную и добавить ее в Cmake

можно завести переменную с путем по умолчанию для Irrlich и Bullet, и менять ее если надо через запуск cmake:

cmake -DPATH_TO_LIBS="../path"

Я, как человек терпевший боль, от множественного использования переменных окружения в cmake конфигурациях, настоятельно рекомендую следующую схему.

• Любая конфигурация производится через переменные cmake.
• Если нужен вход из окружения - используется одноимённая с переменной cmake, переменная окружения.
• Переменная окружения имеет наименьший приоритет по сравнению с соответсвующей переменной cmake.

Иначе, каждая конфигурация будет требовать установленных переменных окружения. Сменить окружение - будет сложно. Изменение окружения не будет отслеживаться cmake'om. Окружение легко потерять. Что бы не потерять окружение, его придётся инкапсулировать в платформозависимые скрипты (спрашивается нафига тебе вообще cmake тогда).

:) Разработка будет вестись на Маке и Венде. Что то лучше есть? Я на линуксе хотел юзать KDevelop.

Разработка будет вестись на Маке и Венде. Что то лучше есть?

Чем мак и венда? GNU/Linux, наверное, но не факт.

А если вопрос касался переменных окружения, то pon4ik дал верный ответ - лучше использовать переменные CMake.

CMake - норм, просто есть ряд тонкостей, как и везде.

Я на линуксе хотел юзать KDevelop

На вкус и цвет конечно, но мне больше нравиться qtc для плюсовых проджектов. Во первых кроссплатформа, во вторых, очень удобный и легко расширяемый флоу.

Мне в QtC не нравится рефакторинг. Автодополнение медленное ну и все какое то корявое :)

не позорился бы

Дауж, прекрасное решение :D

Хз, не наблюдаю. Может версию старую тыкал ты?

Надо будет ещё раз потыкать KDevelop.

Человек попросил переменные, их есть у меня!

Я лишь подсказал инструмент)

Переменная окружения имеет наименьший приоритет по сравнению с соответсвующей переменной cmake.

Я что-то пропустил? Переменные окружения и CMake не должны пересекаться. К первым обращаются по $ENV{varname}, ко вторым по ${varname}.

Речь о том, что если ты хочешь таки иметь возможность, конфигурять используя окружение. То, ни в коем разе, у тебя не должны использоваться переменные окружения напрямую, только через кэш.

Иначе, если вдруг, твоё поделие взлетит, и начнёт расти - ты ужаснёшься :)

По этому пункту со всем согласен, сам давно пришёл к выводу, что в CMake любые пути и опции сборки должны попадать только через кеш.

А по какому не согласен?:)

• Если нужен вход из окружения - используется одноимённая с переменной cmake, переменная окружения.
• Переменная окружения имеет наименьший приоритет по сравнению с соответсвующей переменной cmake.

Читая думаешь, что переменная с одним и тем же названием разименовывается в порядке приоритета, сначала значение ищется в переменной CMake, а потом в переменной окружения, что не верно. Ну а концептуально всё через кеш есть правильный способ.

Ну, кстати некоторые встроенные переменные CMake ведут себя именно так.

Например, мего полезный CMAKE_PREFIX_PATH.

Но суть, предьявы я понял, согласен не очень чётко отразил, что это нужно делать руками :)

Я немнго не догнал. Я в bashrc объявил export IRR=/path/to/irr дальше printenv IRR выводит, а в cmake message(«$ENV(IRR)») не выводит. :)