Портативная система сборки С++

Ответ 1

(-) требует файла конфигурации в каждой папке проекта

Это неверно, вам просто нужно передать больше паттов, например:

add_program(foo src/foo.cpp src/main.cpp)

Несколько заметок, о Boost.Jam - сначала это не Boost.Jam - бьям сам по себе совершенно бесполезен, то, что вы ищете, это Boost.Build, который представляет собой набор макросов Jam, которые делают bjam полезным.

Теперь я работал с обоими, и я должен признать, Boost.Build не подходит для каких-либо серьезных проектов за пределами Boost. Нужно найти библиотеку? Не может понадобиться найти заголовок? Не могу. Нужно что-то делать за пределами простой сборки - и вы не знаете, как это сделать, как документацию BB... Абсолютно бесполезно и, возможно, покрывает 10% BB. Поэтому в большинстве случаев вам нужно задавать вопросы в списках рассылки BB и...

Итак, если у вас есть сложный проект, и вам нужно сделать что-то более простое компиляцию и ссылку, держитесь подальше от Boost.Build.

Итак, если вам нужно поддерживать MSVC, я нахожу сегодня CMake как возможный вариант.

Я не говорю, что CMake - очень хорошая система, у нее много проблем, но это что-то в основном подходит для кросс-платформенной разработки (если вам нужно поддерживать MSVC).

И если вы не заботитесь о MSVC и довольны MinGW... посмотрите также на autotools.

О Scons - он все еще менее зрелый их CMake.

Ответ 2

Это немного напыщенная речь, но я постараюсь оставаться объективным и рассказывать только о своем опыте:

Я несколько раз пробовал CMake, и я близок к достижению точки, когда я буду добровольно предлагать отдельные файлы проектов для каждой среды сборки или злоупотреблять другой системой сборки языка (Ant, NAnt, MSBuild или так) для компиляции и упаковки моих проектов на С++.

CMake, как есть:

• Он заменяет уродливый, но формализованный формат (Makefile) с невероятно плохо разработанным свободным форматом (CMakeLists.txt).
• Он удаляет свою конфигурацию, кеш и другие помехи во всех каталогах с нулевым уважением, поскольку пользователь пытается сохранить исходное дерево в чистоте.
• Документация для CMake отсутствует в большинстве мест (например, попробуйте рекурсивно добавить исходный каталог в целевую wile, исключая определенные файлы для стартеров)
• Сгенерированные проекты IDE невероятно плохи (имеют хорошо структурированный проект Visual Studio? CMake сбрасывает все ваши источники в один проект node)
• Сгенерированные проекты IDE используют абсолютные пути (поэтому вы не можете проверить их в исходном контроле - каждый должен использовать CMake)
• Вы можете выбирать между платформами (например, x64 и x86) при создании проектов /make файлов. CMake не будет генерировать проекты, поддерживающие несколько платформ, даже если IDE будет отлично справляться с этим.
• Очень мало контроля над ссылками на библиотеки. Существует множество методов поиска ссылок (так что даже при плохом управлении вы не можете ожидать никакой однородности).

Мое личное мнение состоит в том, что даже если бы кто-то хотел преднамеренно разработать худшую кросс-платформенную систему сборки, было бы трудно сделать что-то хуже, чем CMake.

У меня нет опыта работы с Boost.Build, и у него могут быть одинаково серьезные недостатки, но самое лучшее, что я могу сказать о CMake, это то, что если вы только заботитесь о том, чтобы каким-то образом создать некоторые исходные файлы, он может получить работа выполнена - хотя и с большой болью для разработчиков и пользователей библиотеки/приложений.

Ответ 3

У меня были хорошие впечатления от premake4: http://industriousone.com/premake

Обновление

Мне все еще нравится premake, но после некоторого времени работы я чувствую себя обязанным перечислять некоторые недостатки, которые я нашел в нем:

• Интеграция новых наборов инструментов (например, инструментов предварительной обработки, таких как bison или moc) не поддерживается.
• Нет поддержки для конфигурации каждого файла.
• Поиск библиотек является негибким, без поддержки сценариев или проверки версий.
• Некоторые директивы (например, конфигурация) влияют на следующие операторы, но нет четкого определения границ. Это может привести к незначительным ошибкам.
• Небольшая поддержка отладки конфигурации, другими словами, показывая, как интерпретируется конфигурация, кроме изучения сгенерированных скриптов сборки или их запуска.
• Для gmake Makefiles, по крайней мере, нет возможности сделать абсолютные пути. Это не очень хорошо работает с Vim quickfix, хотя легко работать.
• Медленный темп развития. Новые возможности могут разрабатываться уже много лет.

Ответ 4

Я буду следовать @Akusete на QMake, который сейчас является моим личным инструментом выбора. Плюсы и минусы тоже немного личны, но вот они:

Плюсы:

• Большой язык-посредник script по сравнению с CMake;
• Может генерировать как VS проекты, так и jom-совместимые make файлы в Windows;
• Добавление наборов инструментов для, скажем, кросс-компиляции довольно просто (сводится к настраиваемому mkspec, который написан на том же языке qmake);

Минусы:

• Немного ограничена свобода произвольного количества целей. Существуют некоторые предопределенные, такие как app, lib и т.д., Но немного громоздко строить, скажем, как общие, так и статические версии библиотеки за один проход, или отключить предварительно скомпилированный заголовок для одного исходного файла. Это определенно достижимо, но требует некоторого поиска и выглядит грязным;
• По умолчанию привязан к Qt (который легко переопределяется добавлением строки QT -= core gui)

В целом:

Получает быстро выполняемую работу над простыми и средними проектами, но все же оставляет ощущение "черт возьми, это можно было бы сделать проще". когда применяется к сложным задачам.