История изменений

Неужели гибкости CMake для чего-то не хватает?

Если говорить конкретно про CMake, то это весьма своеобразная система, которая решает искусственно созданные проблемы. Это ведь не система сборки, а система генерации скриптов сборки для других систем. И в этом смысле её возможности весьма сильно ограничены. Потому что генерируется оно CMake-ом (исполнение cmake-скриптов), а вот исполняться будут другой системой.

Например, если у тебя есть в проекте кодогенератор, и он создает много файлов, имена этих файлов должны быть известны на этапе выполнения cmake-скрипта, чтобы последний мог создать граф зависимостей между файлами. Но кодогенератор твой выполняется на этапе сборки, т.е. запускается уже make-ом, msbuild-ом или ninja. Поэтому приходится запускать кодогенератор дважды: один раз cmake-ом непосредственно в --dry-run режиме, когда он ничего не делает, а только создает список файлов. И второй раз уже на этапе сборки. Это не то, чтобы неудобно, но кодогенератор должен быть уметь интегрироваться с cmake (сообщать список создаваемых файлов). Ну и, каждый раз, когда генератор может создать дополнительный файлы, нужно перезапускать cmake на проекте. Если ты сам руками добавляешь новый исходник, то ты знаешь, что надо cmake перезапустить. А что там кодогенератор насоздает — глазами это не видно.

Иными словами, cmake не может создавать скрипты сборки для динамических графов зависимостей между файлами. А эту возможность очень хотелось бы иметь.

Сейчас ситуация еще более щекотливая. Ninja кроссплатформенный и стал уже фактически стандартом сборки. И cmake над ним уже воспринимается как совершенно лишняя сущность. Cmake по сути нужен только тогда, когда тебе нужно проект для сборки в VC сгенерить.

И вот чтобы хотел видеть, так это, как минимум, нормальная кроссплатформенная система сборки без генераторов конфигураций над ней. А если сейчас вдруг cmake стандартизируют под давлением народных масс, то это будет мега-фейл, так как cmake — это костыль.

Позже отпишусь, что же именно я бы хотел видеть.

Неужели гибкости CMake для чего-то не хватает?

Если говорить конкретно про CMake, то это весьма своеобразная система, которая решает искусственно созданные проблемы. Это ведь не система сборки, а система генерации скриптов сборки для других систем. И в этом смысле её возможности весьма сильно ограничены. Потому что генерируется оно CMake-ом (исполнение cmake-скриптов), а вот исполняться будут другой системой.

Например, если у тебя есть в проекте кодогенератор, и он создает много файлов, имена этих файлов должны быть известны на этапе выполнения cmake-скрипта, чтобы последний мог создать граф зависимостей между файлами. Но кодогенератор твой выполняется на этапе сборки, т.е. запускается уже make-ом, msbuild-ом или ninja. Поэтому приходится запускать кодогенератор дважды: один раз cmake-ом непосредственно в --dru-run режиме, когда он ничего не делает, а только создает список файлов. И второй раз уже на этапе сборки. Это не то, чтобы неудобно, но кодогенератор должен быть уметь интегрироваться с cmake (сообщать список создаваемых файлов). Ну и, каждый раз, когда генератор может создать дополнительный файлы, нужно перезапускать cmake на проекте. Если ты сам руками добавляешь новый исходник, то ты знаешь, что надо cmake перезапустить. А что там кодогенератор насоздает — глазами это не видно.

Иными словами, cmake не может создавать скрипты сборки для динамических графов зависимостей между файлами. А эту возможность очень хотелось бы иметь.

Сейчас ситуация еще более щекотливая. Ninja кроссплатформенный и стал уже фактически стандартом сборки. И cmake над ним уже воспринимается как совершенно лишняя сущность. Cmake по сути нужен только тогда, когда тебе нужно проект для сборки в VC сгенерить.

И вот чтобы хотел видеть, так это, как минимум, нормальная кроссплатформенная система сборки без генераторов конфигураций над ней. А если сейчас вдруг cmake стандартизируют под давлением народных масс, то это будет мега-фейл, так как cmake — это костыль.

Позже отпишусь, что же именно я бы хотел видеть.