Системы сборки С++

Ответ 1

Я использовал SCons уже более года, и это действительно здорово. Это полная система сборки, а не генератор скриптов сборки.

Он основан на Python, и вы пишете SConstruct и SConscript (эквивалент Makefile) в Python, который позволяет вам вызывать любую доступную библиотеку, которую вы можете пожелать, и более четкий синтаксис, который разрешает авторизация Makefile.

Поскольку Python является кроссплатформенным, то есть SCons, без проблем.

Он поставляется в комплекте с большим количеством целей:

• обнаруживает доступный двоичный файл и автоматически отображает ряд расширений в сторону правильных двоичных файлов
• обнаруживает правильные расширения для ваших объектов/библиотек в зависимости от ОС, хотя вы можете переопределить его
• предоставляет средства для общих операций (задержка после сборки), таких как Move, Copy, Tar, и вы можете предоставить свои собственные скрипты python и подключить их.
• работает из коробки и при этом обеспечивает множество перехватов настроек на каждом уровне.

Он действительно эффективен и даже предлагает расширенные функции (например, сохранение хэша предварительно обработанного файла в sqlite db вместо использования метки времени), даже если вы решите свою стратегию в конце.

Он также предлагает бесплатное обнаружение циклов зависимостей (что определенно не связано с Make файлами), и интерфейс обычно лучше/автоматизирован.

Я сказал, что это эффективно? Ну, это, очевидно, позволяет выполнять несколько заданий параллельно;)

И это также бесплатно, как и в бесплатном напитке, не стесняйтесь вносить свой вклад;)

Я могу только рекомендовать его.

Ответ 2

У меня нет опыта работы с остальными, но если вы ищете кросс-платформенную систему построения кросс-цепей, используйте CMake. CMake на самом деле не является системой сборки, это генератор сборки script - он генерирует сценарии сборки для многих систем сборки и (и это, на мой взгляд, сила) генерирует файлы проектов для основных IDE, таких как Visual Studio и KDevelop. Недавние версии KDevelop, кстати, имеют файлы Intellisense для CMake.

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

Недостатком CMake является то, что на самом деле он не поставляется с множеством встроенных инструментов или простым способом его расширения (по сравнению, например, с MSBuild, который, конечно же, представляет собой только систему сборки, а не генератор), Наши разработчики Linux имеют тенденцию вызывать инструменты командной строки Unix, чтобы делать такие вещи, как сжатие/декомпрессия, которые недоступны при обычной установке Windows, в то время как MSBuild имеет тысячи дополнительных команд, доступных из проектов сообщества, поэтому вам не нужно использовать в командной строке, и очень легко создать новую задачу для MSBuild. В настоящее время я изучаю, как обойти эти ограничения для CMake, поскольку в настоящее время это означает, что мы не можем полностью строить на Windows, даже несмотря на то, что сам код будет хорошо создан.

Написание файлов CMake не является прекрасным опытом, но все в порядке. Язык имеет некоторые странные причуды (например, нужно точно повторять if-условие в else и endif, что сбивает вас с ума, особенно при экспериментировании), и вы действительно будете очень ненавидеть наличие файла под названием CMakeLists.txt в каждом и каждый каталог, который имеет пользовательские правила сборки (и это может быть много, в большом проекте), и все они отображаются только с именем в вашей IDE;)

Ответ 3

Через несколько лет в будущем...

• SCons отмирает от популярности, от того, что я видел. Мне это совсем не нравится.
• Waf является удивительным (на мой взгляд). Если вы изучаете SCons, сначала попробуйте Waf. Однако параллельные сборки всегда показывают вам все ошибки, которые произошли... поэтому ожидайте, что ваш экран будет заполнен сообщениями об ошибках. Кроме того, это может немного осложниться.
• Boost.Build является одним из моих любимых, но имеет худшую документацию на земле. Помимо этого, он очень гибкий и позволяет делать практически все. Тем не менее, это может быть немного медленнее.
• CMake хорош только для создания сценариев ниндзя; все остальное - мусор (4000 строк make файлов для 1-исходного 1-исполняемого проекта)
• Tup хорошо, но для конфигурации ничего не требуется.
• Autoconf по-прежнему autocrap.

Другие, не упомянутые:

• Kbuild немного странно, но выглядит красиво. Это все, что я знаю.
• mk-configure отлично подходит для любителей.
• Shake с shake-language-c является гибким и позволяет вам делать что-либо... если вы знаете Haskell и не возражаете отказаться от поддержки VS.
• Jamplus любит перетаскивать -m32 в конце каждой неудачной команды компилятора, которая отсасывает 64-битную систему.
• Tundra может быть чересчур повторяющимся, но все еще очень быстрым и точным.
• Bam... Тундра лучше. Он быстро, не жертвуя точностью.
• Gyp (используется для Google Chrome/Chromium) недооценивается, но является отличной альтернативой CMake.
• Premake отлично, если вы цените простоту, но он может раздражать, когда он приходит, делая кажущиеся простыми вещи.
• Bakefile очень ограничительный, но отличный для простых проектов.
• fbuild - мой любимый (вместе с Boost.Build). Он довольно недооценен, но имеет множество примеров и очень читаемый исходный код. Строковые скрипты тоже короткие. Он использовался для создания (и был разработан для Felix. Он также очень, очень быстрый, и он почти всегда абсолютно точен и имеет автоматический parallelism, который НЕ наводняет ваш экран. Когда-либо. Я использую его для создания JRE-механизма регулярного выражения и очень, очень счастлив. Это также очень легко расширить. Тем не менее, это по-прежнему технически в бета-версии, хотя я никогда не испытывал никаких реальных проблем.

Я бы рекомендовал fbuild или Boost.Build... или Gyp, если вам нравятся генераторы makefile.

Если вы хотите расширить базовую функциональность, определенно используйте fbuild. Если у вас есть БОЛЬШИЕ флагов/опций платформы и множество беспорядков, используйте Boost.Build. Если вам нужен генератор makefile или у вас много настроек, попробуйте Gyp.

Ответ 4

У меня была возможность сравнить все из них. Сначала мы использовали make. Это уродливо. Вы должны быть экспертом, чтобы действительно понять, что происходит. Я больше не буду принимать боль.

Затем мы перешли к SCons. Это синтаксис в порядке, вы все равно можете делать уродливые вещи, потому что вы можете писать свои собственные скрипты, которые, как правило, являются программами. Это дает вам большую гибкость. Но мы пнули SCons, потому что нам пришлось ждать около 20 секунд для сканирования проекта и еще 20 для сборки каждый раз. Затем мои колледжи писали код python, чтобы кэшировать результаты сканирования в файлы и почти удвоить производительность. Вам все равно пришлось подождать около 20 секунд для сборки, когда вы добавили файл или удалили его из проекта, который вам нужно было перезапустить с помощью параметра -fill-cache.

Затем я переместил проект в CMake, что, безусловно, является моим инструментом выбора. Его структура и синтаксис очень хорошо читаются и также документируются. Он генерирует ваши проекты практически для всех IDE, а также для ранней поддержки новых IDE на рынке. Процесс сборки выполняется так же быстро, как и IDE, и вам нужно вернуться в CMake только при добавлении новых проектов или изменении свойств проекта, чтобы оставаться с CMake

Поэтому я бы предложил CMake

Ответ 5

Другим инструментом является TUP. Мой опыт хорош с этим инструментом. Tup

• Автоматически обрабатывает зависимости (нет необходимости вызывать gcc -M).
• Работает с графами с частичной зависимостью, поэтому очень быстро.
• Он поддерживает рекурсивные структуры каталогов блестящим способом (Tuprules.tup)
• Поддерживает git выдающимся образом: может автоматически создавать файлы .gitignore на основе целевого списка.
• Чрезвычайно прост в использовании и синтаксис для Tupfiles очень прост.
• Он поддерживает последовательную сборку исходных файлов, даже если вы переименовали файл или удалили его. Поэтому построенные двоичные файлы всегда отражают текущее состояние источника. Это также означает, что вам никогда не понадобится очищать ваш проект.

После использования его для двух довольно сложных проектов я могу сказать только одну плохую вещь:

• Сложно использовать вместе с динамическими представлениями ClearCase.

Ответ 6

Взгляните на Waf. Это достойная система, которую я использую для большинства моих проектов, написанных на питоне и полученных из Scons, Make и других систем подобного типа.

Ответ 7

Из того, что вы упомянули, я пробовал Maven - он слишком строгий, не масштабируется и предназначен для Java, поэтому я бы не стал его рассматривать. Я также слышал от людей, которые использовали "Automake", которые они в шутку называют "Autobreak"

ИМХО, проект с долгой надежностью предпочтет чисто Make, GNU Make, если быть точным. Существует несколько мощных функций Make, обычно не используемых, которые помогают избежать кода шаблона (например, использование eval/call, нерекурсивная сборка). Он совместим с любой другой системой сборки (например, в наших проектах мы успешно объединяем его с Ant, используемым для сборки Java). Он имеет отличную документацию и знаком большинству разработчиков.

Из моего опыта всегда можно выделить makeystem из проекта в той степени, в которой большинство make файлов проекта содержат 2 строки: имя целевой и "include ${MKSYS_HOME}/makesystem.mk.

Ответ 8

Я пробовал:

• scons < --- Слишком медленно.
• waf < --- Довольно хорошо, но, с моей точки зрения, чрезмерно. Иногда нелегко угадать, что делать.
• cmake < --- Не красивый синтаксис, но довольно надежный и довольно быстрый.
• autotools (документы mythbuster) &lt --- --- Только unix. Лучшая обработка кросс-компиляции.
• tup < - Это так быстро и правильно, что это невероятно.

Вы ищете промышленную силу. Я бы сказал, что у нас нет брака, потому что он слишком медленный ИМХО, даже если это было хорошо. Он также не имеет фазы конфигурации.

waf выглядит хорошо, но я нашел, как бороться с некоторыми вещами, особенно вложенными проектами, правильным способом.

autotools ДЕЙСТВИТЕЛЬНО надежный, хотя он не поддерживает Windows. Кросс-компиляция действительно надежна в autotools.

CMake: Думаю, вам стоит пойти на это. Это довольно быстро, он управляет конфигурацией, как и autotools, но работает в окнах, генерирует проекты для xcode, visual studio, make и многое другое. Это хорошая функция, если у вас есть многоплатформенный проект, поскольку вы можете создавать проекты для избранных IDE. Но я должен сказать, что мне не нравится синтаксис слишком много. Во всяком случае, он отлично справляется с большими проектами. Я хотел бы пойти на cmake, если бы захотел "индустриальной силы". Даже если я лично немного ненавижу его, это единственный жизнеспособный вариант.

Tup: Я думаю, что он более ориентирован на UNIX. Но я должен сказать, что для меня это самое приятное, и это безумно быстро и просто. Я люблю это. Но вам нужен cmake.

Ответ 9

Другой взгляд на Bakefile.

Его основная сила заключается в том, что требуется относительно простой входной файл (простой, как XML получает, во всяком случае) и выставляющий много разных исходных системных файлов: Makefile.in в системах на основе autoconf (Linux, OS X command line, BSD...), Visual С++ решение и файлы проекта, проекты Xcode, MinGW и общие Unix Make файлы и т.д.

Тем не менее, я не знаю, что с самого начала я бы использовал такую ​​систему. Поскольку исходной целью является Linux, а остальные - "майбы", подумайте о начале работы с automake и поместите Bakefile (или что-то еще), пока вы не портируете. Всегда нужно строить вещи, прежде чем они вам понадобятся. В этом случае всегда есть компромисс - самый низкий синдром общего знаменателя - и если вам не нужно платить штраф сегодня, отложите его, пока вам не придется платить; вам, возможно, никогда не придется платить. Если вы пойдете с automake и соедините свои файлы, переход не будет слишком болезненным.