Пока я развиваюсь в C/C++ и Java, я просто делаю скрипт compile.bat, который делает все, это хорошо для меня. Почему я должен использовать make и почему я должен использовать ant?Какова реальная полезность make и ant?
Предположим, у вас есть 1000 исходных файлов и смените только один из них. С вашим сценарием .bat вам придется перекомпилировать партию, чтобы вы перекомпилировали только тот, который изменился. Это может немного сэкономить (чтение часов в большом проекте) времени.
Еще лучше, если вы измените один из ваших файлов заголовков, make будет перекомпилировать только исходные файлы, которые используют этот заголовок.
Это две основные функции, которые означают, что make и его детище используются для всей серьезной разработки программного обеспечения на скомпилированных языках.
Черт, даже на проекте одного человека нетрудно добраться до нескольких минут чистой сборки на быстрой машине. – dmckee
Существует также возможность поддерживать создание нескольких версий (отладка, выпуск, платформа), автоматизировать тестирование, установку и т. Д. Да, вы можете сделать все это, скопировав свои собственные скрипты, но зачем изобретать колесо еще раз? –
И если ваши зависимости в make-файле точны, вы можете сделать параллельную сборку, просто набрав 'make -j N', где' N' - количество заданий, которое вы хотите запускать за раз, - отличное ускорение на многоядерном процессоре. – Dan
С одной стороны, make и ant отслеживают, какие файлы уже скомпилированы, поэтому он не выполняет повторную работу, если он не нужен.
С файлом сборки вы можете автоматизировать больше, чем просто компилировать свой код; вы можете запускать модульные тесты, собирать метрики, артефакты сборки пакетов для развертывания и многое другое.
Достоинством Ant является то, что он вдохновил инструменты для других платформ - NAnt для .NET, Phing для PHP. Они делают то же самое и работают одинаково.
Пока вы разрабатываете для себя под Windows: подходите сами.
Но если вы начнете разрабатывать вместе с другими, Ant и Make станут стандартом для описания того, как ваше приложение построено.
+1: файл .bat будет работать * только * в Windows, файл '.sh' будет работать * только * в Unix (да, я знаю ...). Файл Ant 'build.xml' будет работать везде, где вы можете запустить Ant. –
@JoachimSauer ANT строит только работу везде, где ANT был установлен, так же, как SH-скрипты требуют установки sh, поэтому я не уверен, что Ant является «везде» таким образом, что «sh» нет. – davenpcj
Там может быть несколько причин: - потому что вы не единственный в проекте - потому что кто-то должен заботиться о сценарии сборки, когда вы оставили - потому compile.bat сценарий не зависит от платформы - потому что политика проекта определяет технологию сборки, например для всего предприятия
Недавно я прочитал смешно article about build tools. Для вас может быть интересна только первая часть (до начала избиения maven)
Вы получаете некоторую нейтральность платформы (как я могу запустить ваш пакетный скрипт в моем linux-box). Но что более важно: встроенные инструменты поддерживают поддержку зависимости. Скриптам этого не хватает, и их нужно строить самостоятельно.
Скажите, что у вас есть цели A, B и C. B и C оба зависят от A. В скрипте они вызывают подпрограмму A. Если теперь вы создаете новую цель D, которая зависит от B и C, чем вы выполнить A дважды. Build-tools распознают это и выполняют A только один раз.
Поскольку эта ситуация типична для задачи, связанной с компиляцией, построением дистрибутива, тестирования, строительной документации и т. Д., Сборщики полезны для разработки программного обеспечения.
Можно было бы использовать файл .bat - или bash или другой колористический скрипт - сделать все, что может сделать Ant, я считаю. Но намного проще сделать многое в Ant ...
Многие проекты должны сделать это вещи, в дополнение к компиляции, когда они строят.
Также Ant не зависит от платформы, поэтому вы можете сотрудничать с теми, кто использует другие операционные системы.
Но зачем останавливаться на Ant? Apache Maven предлагает еще более привлекательные функции.
Make and Ant действительно приходят в свои руки при использовании с автоматизированными системами сборки или непрерывной интеграцией.
Требования к производственным сборкам, тестовым сборкам и разработкам часто отличаются друг от друга, а в команде с несколькими людьми различные разработчики устанавливают свои среды разработки по-разному.
Выполнение окончательного процесса сборки решает проблемы «Works on My Machine» (WOMM), возникающие всякий раз, когда приложение должно быть построено на другой машине с той, на которой она была разработана. Это конечный арбитр, когда один разработчик проверяет код, который не работает на машине другого разработчика. Если процесс сборки не создает рабочего программного обеспечения, регистрация первого разработчика была нарушена. Если он создает рабочее программное обеспечение, тогда среда разработки второго разработчика будет нарушена, если не будет доказана обратная.
кросс-платформенный и т. Д. –
почему слово real? это означает, что существует «предполагаемая» утилита, но вы не говорите, какой из них. Я предполагаю, что вы просто спрашиваете, что такое утилита. – Dan
Если вам нужно спросить, что значит использовать make или ant, вы не готовы понять разницу между ними. :-) – JesperE