Здравствуйте, zaufi, Вы писали:

Ключи компиляции

Z> ну не знаю... играться какими-то ключиками компилятору из командной строки вообще не хочется... не потому что "неудобно" (у меня как раз удобный shell и терминал) и я даже помню много ключей gcc так что мне не нужен man... но вот коллеги далеко не все знают это и хотят помнить %) наборов ключей на сам деле довольно не много -- и для их управления как нельзя лучше подходят "профайлы". кроме стандартных debug/release я добавляю extreme-optimize и extreme-debug... стандартные minsize/release-with-debug-info в общем и не использую. указывать конкретные ключи в CLI как-то вообще не выглядит хорошей идеей...

Вам никогда не приходилось каскадно добавлять -m32 к ключам компиляции? Если нет, то поздравляю, вам не приходится заниматься кросс-компиляцией. А если вы не добавляете -fsanitize=address (в том числе и к релизным билдам) то НЕ поздравляю, так как вы не используете одно из лучших средств обнаружения ошибок, доступных на текущий момент. Ну и много других случаев, когда хочется каскадно поменять ключи, собрать и потестировать.

V>ИМХО реальный смысл использовать target_compile_options а не CMAKE_C_FLAGS/CMAKE_CXX_FLAGS есть тогда, когда в подпапке более одного таргета, и у им нужны разные ключи. Мне чаще наоборот хочется, чтоб была каскадность -- чтоб всё, что в подпапках, использовало данные ключи.

Z>это устаревшее представление -- где-то из CMake 2.x ветки -- реальной необходимости манипулировать этими переменными щаз вообще нет!

Хммм. Всё что мне "щаз" не нужно -- не нужно никому (C).

Ещё раз, разница с использованием CMAKE_C_FLAGS/CMAKE_CXX_FLAGS и target_xxx -- CMAKE_XXX каскадные, target_xxx -- нет. Что нужно в конкретном случае -- зависит от конкретного случая. Хотя, если "играться какими-то ключиками компилятору из командной строки вообще не хочется", то возможно вам ни того, ни другого и не надо. Тогда понимаю.

Z> оч рекомендую заштудировать доки CMake по управлению требованиями... оно может показаться непонятным с первого прочтения, но уверяю тебя, оно стоит 2х-3х внимательных чтений и экспериментов чтобы догнать все идеи.

Ого, что это сейчас было? Типа собеседник настолько туп, что надо не просто отослать его читать eff-ing manual, но ещё и порекомендовать сделать это 2-3 раза -- и внимательно, а то с первого прочтения этот дуб не догонит?

Надеюсь, я вас неправильно понял

V>Тоже начинал с поиска (естесвенно), нашёл несколько скриптов разной степени готовности -- но ничего работающего из коробки для GCC и Clang. В итоге написал сам.

Z>gcc и clang вообще ничо сложного... я тогда (во времена cmake 2.6) тоже сделал свой sipeda-motor... сложности начинаются, когда нужно еще и убогий MSVC приучить...

Снова "убогий", что ж ты будешь делать... Три-ноль! Но этот последний гол ещё и рукой забит!

Одна из (немногих) вещей, в которых "убогий"" MSVC лучше, чем GCC/Clang -- это человеческая реализация precompiled headers. Ей удобно пользоваться и она реально ускоряет компиляцию больших проектов -- в разы!

В gcc/clang поддержка pch сделана для галочки, просто чтоб была. Ускоряет компиляцию процентов на 10-20 и неверорятно сложна в настройке, особенно из CMake -- поэтому ей в подавляющем большинстве проектов просто не пользуются.

Да, и раз уж "ничо сложного" -- будьте добры, покажите ваш CMake-скрипт для gcc-pch. Потом сравним его со скриптом для включения pch в "убогом" MSVC