Системы сборки на Java
При изучении любого языка программирования и написании учебных программ достаточно только среды разработки, где код можно скомпилировать и запустить, но для промышленных проектов нужно обязательное знание систем сборщиков. В этой статье разберемся, зачем они вообще нужны и какие существуют для Java.
Зачем нужна система сборки
Когда компьютеры только начинали свое существование, системы сборки не были нужны, программы писались под определенные ЭВМ. С развитием индустрии серверы для разработки отделились от промышленных(“продакшен”) серверов, на которых разработанные приложения должны были использоваться.
Вы можете запускать приложения в среде разработки, но тогда вам понадобится установить ее на все компьютеры заказчика, разложить исходные коды по нужным папкам, установить все требуемые библиотеки и так далее. Очевидно, что это неудобно.
Поэтому и появились системы сборки: они не зависят от IDE и автоматически выполняют действия, перечисленные выше.
Какие бывают системы сборки
Система сборки — это скриптовый код, написанный обычно на определенном языке программирования. Следовательно, для каждого языка они разные. Большинство основаны на самом первом сборщике — Linux-утилите make. Она использует специальные make-файлы, в которых подробно расписаны зависимости файлов друг от друга и порядок их сборки. Этот подход появился еще в 1976 и использовался всеми языками программирования, в том числе Java до разработки собственного средства.
Давайте узнаем подробнее о сборщиках Java.
Первым из них был Apache Ant (Another neat tool). По схеме работы очень похож на утилиту make, но вместо make-файла, состоящего из команд Bash, использует файл формата XML. Вот пример build.xml файла для простого проекта “Hello World”.
Фазы сборки называются целями (<target>). В этом файле их 4: clean, compile, jar и run. Например, при вызове
Сначала отработает clean, который удалит каталог «classes». После этого compile заново создаст каталог, который скомпилируется в папку src, все как определил разработчик. И вообще, поскольку Ant не навязывает никаких соглашений о структуре проекта, программисты сами пишут все команды и определяют порядок сборки.
Что не так?
Ant-файлы могут разрастаться до нескольких десятков мегабайт по мере увеличения проекта. Здесь все выглядит неплохо, но на промышленный проектах они длинные и неструктурированные, а потому сложны для понимания.
Что привело к появлению новой системы
Apache Maven
Хоть он также использует XML для построения конфигурации (файл называется POM.xml), но имеет серьезные отличия:
1. Здесь есть четкая структура каталогов, и вы обязательно должны ей следовать. (При использовании плагинов IDE, она создается автоматически).Она выглядит вот так:
И если вы, к примеру, поместите файл с тестами в папку с ресурсами, то ваше приложение просто не скомпилируется.
Также у каждого проекта может быть только один файл JAR файл, тогда как при сборке Ant модификации были безграничны: вы вообще можете добавить файл в какую угодно папку, собрать 5 классов в 3 JAR-а и так далее. Все это, безусловно, ухудшало поддерживаемость кода.
2. Автоматическое управление зависимостями
В промышленных проектах зависимостей очень много. В Ant вы должны все скачать вручную, распаковать, подключить и обязательно помнить, какую вы используете версию. А вот Maven все делает сам, только напишите, что вам нужно.
3. Стандартизированные названия билдов
Каждый билд имеет атрибуты groupId, artifactId и version. Первые два уникальны и используются для определения в репозитории. Обычно groupId — доменное имя организации, а artifactId — название текущего проекта. Поэтому эта пара и является определяющей: нет двух компаний с одинаковым доменом, как и не существует двух одинаковых проектах в одной компании.
4. Жизненный цикл и плагины
Жизненный цикл maven-проекта — это список фаз, определяющий порядок действий при его построении. Он содержит три независимых порядка выполнения: clean, default и site.
Для расширения и модификации стандартных ЖЦ используются плагины. Ниже представлен пример плагина, который копирует зависимости в ваше директорию.
Плагины, хоть и предоставляют программистам дополнительные возможности, но Maven не дает большой свободы модификаций. Программисты решили взять лучшее из двух миров и разработали Gradle.
Gradle
Оба, и Ant, и Maven используют XML для конфигурирования сборки. Gradle — предметно-ориентированный язык на основе Groovy. И это его основное отличие от Maven. В остальном Gradle руководствуется теми же принципами. Здесь за выполнение всей работы также ответственны плагины и нет широкой свободы действий.
Приведем пример файла build.gradle для того же проекта с HelloWorld
Gradle распространен в мобильной Android- разработке, а Maven используется в системах управления предприятиями. Почему так? Вопрос остается открытым. Возможно, так просто сложилось. Но Maven все-таки гораздо популярнее на рынке и будет полезен Java-разработчикам в любом случае.
Что такое «система сборки» во встроенном домене?
Я работаю в области программирования на C, и кто-то спросил меня, какова система сборки моего проекта. Я работаю в STM32CubeIDE, используя | GNU Tools для STM32 | Набор инструментов . Мне не нужно было создавать Makefile для моего проекта, так как он автоматически генерируется IDE. Так что же такое build-system? Имеется в виду, как я строю проект?
Имеет ли изображение ниже какое-либо отношение к системе сборки?
Любая информация будет полезна. Спасибо.
2 ответа
Он спросил вас, как вы строите свой проект. Это make, cmake, VSbuild или что-то еще.
Возможно, вы используете autotools или другую систему генерации проектов.
Поскольку он установлен на «внешний компоновщик» и инструменты GNU, то, вероятно, make — хотя и не обязательно — IDE может реализовать собственное управление, а не явно генерировать и выполнять make-файл.
Если вы используете исключительно IDE для управления и генерации сборки для вас, тогда « STM32CubeIDE with GNU Tools », вероятно, также является разумным ответом, независимо от того, как он на самом деле его реализует. Знание того, какой инструмент он использует под капотом, полезно, например, если вам приходится собирать командную строку для непрерывной интеграции или автоматического выпуска.
C++
Системы сборки
В настоящее время нет универсальной или доминирующей системы сборки для C ++, которая является популярной и кросс-платформенной. Тем не менее, существует несколько крупных систем построения, которые привязаны к основным платформам / проектам, наиболее заметным из которых является GNU Make с операционной системой GNU / Linux и NMAKE с системой Visual C ++ / Visual Studio.
Кроме того, некоторые интегрированные среды разработки (IDE) также включают специализированные системы сборки, которые будут использоваться специально с родной средой IDE. Некоторые генераторы системы сборки могут генерировать эти собственные форматы IDE / форматы проекта, такие как CMake для Eclipse и Microsoft Visual Studio 2012.
Создание среды сборки с помощью CMake
CMake создает среду сборки практически для любого компилятора или IDE из одного определения проекта. В следующих примерах показано, как добавить файл CMake в кросс-платформенный код «Hello World» C ++ .
Файлы CMake всегда называются «CMakeLists.txt» и должны уже существовать в корневом каталоге каждого проекта (и, возможно, в подкаталогах тоже). Основной файл CMakeLists.txt выглядит так:
Этот файл сообщает CMake имя проекта, какую версию файла ожидать и инструкции для создания исполняемого файла под названием «HelloWorld», для которого требуется main.cpp .
Создайте среду сборки для вашего установленного компилятора / IDE из командной строки:
Создайте приложение с помощью:
Это создает среду сборки по умолчанию для системы, в зависимости от ОС и установленных инструментов. Держите исходный код в чистоте от любых артефактов сборки с использованием «внекорпоративных» сборников:
CMake также может абстрагировать основные команды платформы оболочки из предыдущего примера:
CMake включает в себя генераторы для ряда общих инструментов сборки и IDE. Чтобы создать make — nmake для nmake Visual Studio :
Компиляция с GNU make
Вступление
GNU Make (стиль make ) — это программа, предназначенная для автоматизации выполнения команд оболочки. GNU Make — это одна конкретная программа, которая подпадает под семейство Make. Они остаются популярными среди Unix-подобных и POSIX-подобных операционных систем, в том числе производных от ядра Linux, Mac OS X и BSD.
GNU Make особенно примечателен тем, что он подключен к проекту GNU, который подключен к популярной операционной системе GNU / Linux. GNU Make также имеет совместимые версии, работающие на разных вариантах Windows и Mac OS X. Это также очень стабильная версия с историческим значением, которое остается популярным. Именно по этим причинам GNU Make часто учат вместе с C и C ++.
Основные правила
Чтобы скомпилировать с make, создайте Makefile в каталоге проекта. Ваш Makefile может быть таким же простым, как:
Makefile
ПРИМЕЧАНИЕ. Убедитесь, что отступы имеют вкладку, а не четыре пробела. В противном случае вы получите сообщение об ошибке Makefile:10: *** missing separator. Stop.
Чтобы запустить это из командной строки, выполните следующие действия:
Инкрементальные сборки
Когда вы начинаете иметь больше файлов, make становится более полезным. Что делать, если вы отредактировали файл a.cpp, но не b.cpp ? Перекомпиляция b.cpp займет больше времени.
Со следующей структурой каталогов:
Это будет хороший Makefile:
Makefile
Снова посмотрите вкладки. Этот новый Makefile гарантирует, что вы только перекомпилируете измененные файлы, минимизируя время компиляции.
Документация
Строительство с помощью SCons
Вы можете построить кросс-платформенный код «Hello World» C ++ , используя инструмент разработки программного обеспечения Scons — A Python- language.
Сначала создайте файл SConstruct (обратите внимание, что SCons будет искать файл с этим точным именем по умолчанию). На данный момент файл должен находиться в каталоге прямо по вашему hello.cpp . Напишите в новом файле строку
Теперь, с терминала, запустите scons . Вы должны увидеть что-то вроде
(хотя информация будет зависеть от вашей операционной системы и установленного компилятора).
Классы Environment и Glob помогут вам настроить конфигурацию. Например, файл SConstruct
создает исполняемый hello , используя все файлы cpp в src . Его CPPPATH — это /usr/include/boost и он указывает стандарт C ++ 11.
Ниндзя
Вступление
Система сборки ниндзя описывается на веб-сайте проекта как «небольшая система сборки с акцентом на скорость». Ninja предназначен для создания файлов, созданных генераторами системных файлов, и использует низкоуровневый подход для создания систем, в отличие от более высокоуровневых системных менеджеров, таких как CMake или Meson.
Ninja в основном написан на C ++ и Python и был создан как альтернатива системе сборки SCons для проекта Chromium.
NMAKE (Утилита технического обслуживания Microsoft)
Вступление
NMAKE — это утилита командной строки, разработанная Microsoft для использования в основном в сочетании с инструментами командной строки Microsoft Visual Studio и / или Visual C ++.
NMAKE — это система сборки, которая подпадает под семейство систем сборки, но имеет определенные отличительные особенности, которые отличаются от Unix-подобных программ Make, таких как поддержка синтаксиса пути к файлу Windows (который сам по себе отличается от путей файлов в стиле Unix).
Autotools (GNU)
Вступление
Autotools — это группа программ, которые создают GNU Build System для данного программного пакета. Это набор инструментов, которые работают вместе для создания различных ресурсов сборки, таких как Makefile (для использования с GNU Make). Таким образом, Autotools можно считать генератором системы де-факто.
Некоторые известные программы Autotools включают в себя:
- Autoconf
- Automake (не путать с make )
В общем, Autotools предназначен для создания Unix-совместимого скрипта и Makefile, чтобы позволить следующей команде создавать (а также устанавливать) большинство пакетов (в простом случае):
Таким образом, Autotools также имеет отношение к определенным менеджерам пакетов, особенно к тем, которые подключены к операционным системам, которые соответствуют стандарту POSIX.
Система сборки для больших модульных проектов
На страницах нашего блога мы уже писали о преимуществах организации репозитория крупного проекта способом, предполагающим возможность извлечения исходников в изменяемую структуру рабочей копии. Использование такого подхода вкупе с потребностями простого конфигурирования, фрагментарной сборки, поддержки несколько десятков ОС под широкий спектр аппаратных платформ стали причиной разработки нами собственной системы сборки. Эта статья рассказывает о найденных нами решениях, которые могут быть интересны разработчикам, сталкивающимися с трудностями поддержки инфраструктуры больших проектов.
Прежде чем перейти непосредственно к техническим деталям следует отметить два важных момента. Во-первых, система работает поверх разработанной нами make-утилиты linmake, об особенностях которой будет рассказано отдельно. И, во-вторых, разработка велась для решения задач производства СУБД ЛИНТЕР (www.linter.ru), что привнесло определенную специфику, но не настолько существенную, чтобы решение не могло быть адаптировано к любому проекту.
Зачем нужно было создавать новую систему сборки?
- из-за того, что в далеком 1999 году не было приемлемого кроссплатформенного инструмента мы были вынуждены долгое время поддерживать две параллельные системы сборки: на основе wmake для windows и make для *nix;
- разнообразие поддерживаемых UNIX-like платформ привело к увеличению (а значит и усложнению) вариантов компиляции и компоновки в модулях проекта;
- в свою очередь, сборка windows версии усложнялась необходимостью поддержки большого количества компиляторов;
- не существовало простого механизма описания и разрешения как внешних и внутренних зависимостей проекта.
- система должна однообразно работать на всех поддерживаемых платформах;
- изменение положения модуля (здесь и далее под модулем мы будем понимать функционально самодостаточную часть проекта) в рабочем дереве не должно влиять на работоспособность;
- необходим простой механизм по добавлению новых целевых платформ, архитектур, компиляторов и их версий;
- следует хранить как типовые конфигурации для версий и редакций продукта, так и предоставлять возможность их настройки при необходимости;
- нужен простой способ автоматического учета внешних и внутренних зависимостей в проекте, который бы автоматически определял порядок операций;
- система должна предоставлять возможность простой сборки части проекта со всеми ее зависимостями.
Модель сборки, общие положения
- конфигураций/версий продуктов (CONFIGS);
- целевых платформ (PLATFORMS);
- целевых архитектур (ARCHS);
- компиляторов (COMPILERS);
- версиями компиляторов ($(CMPL)_VERS);
- платформой сборки (HOST.PLT);
- архитектурой платформы сборки $(HOST.ARCH).
Комбинация перечисленных параметров определяет все возможные варианты, которые предварительно фильтруется системой сборки с целью отсеять ненужные и не имеющие смысла комбинации.
В свою очередь, каждый модуль расширяет параметры «для себя» с помощью двух файлов-описателей: для модуля и для процесса сборки, которые написаны в декларативном стиле и не содержат правил (за редким исключением). Описатель модуля содержит общую информацию о модуле: наименование и версии, поддерживаемые платформы, компиляторы и архитектуры, модели потоков, цели. Все объявления (кроме имени) не являются обязательными и в случае их отсутствия используются значения по умолчанию.
Вариант описателя модуля
Описатель сборки объявляет цели, их состав, директивы, директории поиска, внешние и внутренние зависимости модуля.
Вариант описателя сборки
В bldroot структура директорий повторяет srcroot до уровня корней каждого модуля (modsrc), но уже в них, содержатся все фактические варианты, задаваемые допустимыми комбинациями общепроектных и модульных конфигураций. Под каждый из таких вариантов создается директория вида $(MODULE)/$(PLT)_$(ARCH)_$(CMPL)$(CMPLV)_$(TYPE)_$(CFG) (например example/LINUX_AMD64_GCC4_MD_R_base60), будем именовать далее эти директории как modbld.
Вариант содержимого modsrc
Вариант содержимого modbld
- сборка всего проекта/модуля впервые;
- обновление модуля.
Иллюстрация 1: Сборка всего проекта (1) приводит к формированию последовательности вызовов корневого make-файла (3) для всех возможных комбинаций опций сборки (2). В результате фильтрации (3) отсеиваются заведомо непригодные варианты. Файлы описатели модулей, (4) исходя из зависимостей и дополнительных параметров корректируют варианты. Описатели сборки (5) выполняют правила (6) и формируют целевые директории с результатами исполнения (7).
Иллюстрация 2: Обновление существующих модулей (1) работает по упрощенной схеме: вспомогательные правила в modbld (3) обновляют (4) свои цели без использования описателя модуля и фильтров.
Как уже упоминалось выше, все правила вынесены в отдельный модуль (unimake) на уровне проекта, который, помимо заданий самих правил, отвечает за хранение дерева зависимостей между модулями. При этом, каждый модуль из объявленных порождает отдельную цель с генерируемыми зависимыми целями.
Хранение и использование зависимостей между модулями
Благодаря встроенному парсеру файлов размещения модулей linmodules имеется возможность отслеживает текущее положение модулей в дереве исходников и использовать простое определение пути.
Чтение и регистрация модулей и путей
Реализация
Описанный в предыдущем разделе подход был реализован нами для инфраструктуры проекта ЛИНТЕР. И, несмотря на то, что произошло это относительно недавно (около полугода назад) система уже положительно зарекомендовала себя с точки зрения простоты использования, масштабируемости и производительности.