Как составить сборку программ

Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:

1. Написать код приложения

2. Собрать проект

3. Поднять его на сервере приложения

Сегодня я расскажу про второй этап. Сборку приложения можно проводить вручную, но есть также специальные инструменты для этого, которые называются «сборщик продукта». О них мы и поговорим.

Содержание

• Что это такое и зачем он нужен

• Как работает сборщик

  • Проект

  • Свойства

  • Цели

  • Задачи

  • Доп ссылки

• Как запустить сборку

  • Фаза maven: mvn

  • Фаза maven: clean

  • Фаза maven: install

  • Параметр maven: -Dmaven.test.skip=true

  • Флаг maven: -U

  • Фаза maven: test

• Что сборщик умеет делать

  • Компилировать проект

  • Чистить все ненужное

  • Выводить информацию о проекте

  • Обращаться к библиотекам, используемым в проекте

  • Запускать приложение

  • Запускать тесты

  • Другие задачи

• Где хранить скрипт компоновки

• Программы сборки

• Как выбрать программу для сборки

• Итого

• Другие статьи из цикла «Что такое…»

Что это такое и зачем он нужен

Вася решил стать разработчиком, еще будучи студентом. Он выбрал язык программирования Java и начал его изучать. Тренировался на простых вещах:

— Hello Word

— Калькулятор

Сначала весь код его мини-программ хранился в одном файле — Main.java. Чтобы запустить приложение, достаточно было дважды кликнуть этот файл. И всё!

Потом Вася освоил Page Object Pattern и стал разносить логику по разным классам. Но всё равно это были простые программы, и для запуска оставался главный класс.

А потом Вася… Устроился на работу. Да-да, зеленым новичком, и такое бывает! Старший разработчик Николай на собеседовании разглядел в нем потенциал. Так Вася стал джуниор-разработчиком в компании ООО «Котики».

Проект в компании большой, с семилетней историй. Он состоит из 6000 классов исходного кода, над которыми трудятся 5 разработчиков.

В первый рабочий день Николай подошел к Васе и стал рассказывать:

— Наш код хранится в git. Знаешь, что это такое?

— Ага, система контроля версий!

— Да. Вот тебе ссылочка, скачивай.

Вася скачал. Только вот… Что делать дальше? Какой из 6000 классов запустить, чтобы пощупать приложение?

Николай только ухмыльнулся:

— Нет, так оно только для мелких проектов работает. А тебе нужно:

• скомпилировать проект — из исходных текстов получить файлы классов с байт-кодом (которые потом будет исполнять JVM);

• объединить вот эти классы в библиотеку Search.jar;

• объединить вот эти классы в библиотеку Clean.jar;

• объединить вот эти классы в библиотеку Update.jar;

• объединить вот эти классы в библиотеку Report.jar;

• объединить вот эти классы в библиотеку Link.jar;

• а вот эти классы…

Вася в шоке выкатил глаза и промямлил:

— Ээээ, подожди… Мне это выучить надо?

Николай рассмеялся:

— В учебных проектах тебе не надо заморачиваться. Запустил конкретный класс, и всё работает. Ну, может, еще одну-две библиотечки собрал, но это тоже несложно.

Но когда приложение растет, растет и список действий. Вручную его выполнять смысла нет — скука, да и только. К тому же человек легко может ошибиться, а в итоге получим неработающее приложение.

Поэтому эту работу автоматизируют. Можно написать скрипт сборки на коленке, но зачем, если уже есть стандартные сборщики? Скажем, для java это ant, maven, gradle… У нас используется maven, почитай пока о нем.

Сборщик уже настроен, так что тебе достаточно зайти через командную строку в директорию проекта и написать команду:

mvn clean install

А дальше он сам всё сделает. На выходе получим cats.war. Это и есть наше приложение, которое мы потом подложим на сервер wildfly, чтобы его запустить.

— Ага, хорошо, спасибо!

Николай ушел, а Вася завороженно смотрел в экран, где в командной строке работал maven. Быстро-быстро бежали буквы по экрану. И вот, наконец, сборщик остановился. Он написал «BUILD SUCCESS». Значит, всё прошло хорошо. И в нужной директории Вася нашел архив «cats.war».

Пока Николая не было, Вася успел нагуглить это новое слово: «maven». И даже смог найти в проекте скрипт сборки, и начал разбираться, что конкретно там происходит. Всё-таки не зря его взяли на работу! Это отличное качество разработчика (да и не только его) — гуглить и копать самому, а не сидеть сложа ручки в ожидании ментора.

Когда Николай вернулся, он подытожил то, что Вася узнал:

— Когда разработчик пишет код — он просто создает набор файликов с текстом. Чтобы эти файлики превратились в работающее приложение, код нужно скомпилировать и запустить.

Что нужно сделать с кодом-источником:

• скомпилировать проект;

• объединить классы в файл JAR или другую библиотеку;

• установить набор зависимостей;

• …

• запустить конкретный класс или несколько классов.

И только после всех этих манипуляций у нас появляется ПО. Набор манипуляций зависит от конкретного проекта, но чем сложнее проект, тем больше действий надо сделать.

А если задача повторяется снова и снова, она становится первым кандидатом на автоматизацию. Ведь нам нужно что? За один шаг получить работающий проект! Этим и занимаются системы сборки!

— О, стой! Так в IDEA (среда для написания кода) же кнопка «Build» есть. Она ведь тоже билдит, то есть собирает код! Да? Это аналог maven-а?

— Не совсем. Это кнопка:

• компилирует код — проверяет его на наличие простых синтаксических ошибок вида «забыл поставить точку с запятой в конце команды»

• собирает нужные ресурсы (файлы конфигов и подобные) в одну папочку, из которой уже можно запускать программу

— Так если она все собирает и можно программу запускать, зачем maven нужен?)

— Она не собирает само приложение, так как не знает всех зависимостей. Поэтому нужна отдельная программа-сборщик кода.

— А в чем тогда смысл собирать ресурсы?

— Ну, например, для запуска автотестов. Когда мы их запускаем, там не используется полностью варник (приложение cats.war). Там вызываются конкретные функции + используются конкретные ресурсы типа справочника телефонных номеров.

Разработчик исправил код и нажимает «Build». Это обновляет ресурсы, которые используются в тестах. А если тебе нужен варник приложения, то собираешь maven-ом (ну или аналогом).

Комментарий коллеги-разработчика:

— Диалог правильный, но это подход 10-летней давности. Сейчас всё делегируют maven/gradle. В IDE даже галочка есть отдельная для этого. А уже в maven/gradle делаются гранулярные цели для каждой задачи.

— А вообще главное отличие сборщика от IDE — сборщик можно запустить из командной строки, на любом окружении, независимо от среды разработки + в CI/CD системе (TeamCity, Jenkins и тп). Это воспроизводимый билд.

То есть при желании IDEA можно настроить, чтобы она все это делала. Прописать все зависимости и другое, но это будет нерасширяемо.

Как работает сборщик

Сборщики работают примерно одинаково. Базовый функционал:

• компилировать код (проверять на простейшие синтаксические ошибки)

• создавать и удалять директории

• группировать файлы

• …

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

Как сборщик поймет, что именно от него нужно? Благодаря скрипту компоновки. В нем разработчик описывает, что конкректно сборщик должен делать.

Давайте посмотрим, как такой скрипт выглядит, на примере Ant. Ant — инструмент компоновки для Java-проектов.

Файл компоновки Ant — это XML-документ. Он разбит на 4 основные части:

1. Проект

2. Свойства

3. Цели

4. Задачи

В каждом файле компоновки есть проект, и хотя бы одна (умолчательная) цель. Внутри цели находятся задачи — что именно системе надо сделать, если вызвана данная цель.

Проект

Всё в файле является частью проекта. Поэтому тег <project> является корневым в скрипте:

<project name="folks" default="dist">

где:

• name — имя проекта

• default — умолчательная (дефолтная) цель, срабатывающая при запуске скрипта.

Внутри проекта уже находится все остальное — цели, которых мы хотим достичь, и конкретные действия для их достижения.

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

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

Свойства

Свойства Ant похожи на константы. Один раз указали значение, и используем в скрипте хоть в 20 местах. А если значение изменилось, исправить надо будет одно место, а не двадцать. Сюда очень хорошо выносить версии продукта и зависимых библиотек, а также пути к директориям.

Записываются свойства в теге <property>:

<property name="version" value="2.0"/>

<property name="src" location="src"/>

<property name="bin" location="bin"/>

У каждого свойства есть:

1. имя — name

2. значение — value, или место — location (если указываем путь к директории)

Свойства можно переиспользовать, записав как ${имя свойства}

<property name="lib-src" location="${src}/lib"/>

Цели

Цель — это то, что мы хотим получить от сборщика. Краткое название для «я хочу скомпилировать проект» или «я хочу создать все нужные папочки».

Цели записываются в тегах <target>:

<target name=”init”>

<target name=”init” description=”Create the needed directories”>

<target name=”build” depends=”compile”>

Основные атрибуты цели:

• name — имя цели, которое мы будет указывать в командной строке, поэтому лучше делать его коротким. Обязательный параметр.

• description — описание цели. Выводится при запросе информации по проекту.

• depends — от кого эта цель зависит. То есть какую цель надо запустить перед выполнением текущей. Необязательный параметр

В примере цель ”build” зависит от цели ”compile”. Мы не можем начать сборку билда, пока не скомпилировали его. Поэтому, если мы вызываем ant с целью сборки билда, то он:

1. Выполнит цель ”compile”

2. Выполнит цель ”build”

То есть за один присест можно выполнить сразу несколько целей, если прописать их в блоке depends. В данном случае мы вызвали одну цель, а выполнили две. Можно ли выполнить больше? Можно ли указать сразу несколько зависимостей? Да! Для этого надо записать имена целей через запятую в блоке depends:

<target name="D" depends="C,B,A"/>

Call-Graph:  A → B → C → D

Обратите внимание на граф вызова целей. Исходно мы хотим выполнить цель D. Читая атрибут depends, можно подумать, что первой будет вызвана цель C, потом B, и потом A. Это не так! Читать блок depends надо так:

• C зависит от B

• B зависит от A

Таким образом, сначала мы вызываем цель A, потом B, и только потом C. То есть фактически читаем справа налево этот атрибут.

У цели могут быть и другие атрибуты. Например, условие «if». Но подробнее о них читайте в официальной документации Ant — статья «Targets».

Цель по умолчанию

Какой должна быть цель по умолчанию? Должна ли проводиться компиляция, группировка, генерирование документации или все вместе?

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

Но для выполнения всех операций надо использовать ключи шифрования, установщики типа InstallShield и т.д. Стоит ли париться? Многие ставят целью по умолчанию вывод справки по проекту, чтобы новые люди сообразили, что им нужно делать.

Задачи

Задача — это конкретное действие, которое нужно выполнить, чтобы достичь поставленной цели. Например, создать директорию, скопировать файлы, скомпилировать Java-код…

В Ant задача обычно отражает определенную команду: «javac», «mkdir» или даже «javadoc». Именно эта команда и будет названием тега:

<mkdir dir=”bin”/> --- создать директорию «bin»

Эти теги всегда будут внутри тегов <target>. Задача всегда относится к какой-то цели. А вот цель может не иметь задач. Правда, тогда она будет бесполезная =)

Внутри цели может быть одна задача. Например, для компиляции проекта нам нужно скомпилировать java-код в конкретной директории:

<target name=”compile” depends=”init” description=”compile project”>

    <javac srcdir=”src” destrdir=”bin”/>

<target>

При вызове цели compile будет вызвана задача javac. Она компилирует код java в srcdir и складывает классы в destrdir.

Внутри цели может быть несколько задач, как одинаковых, так и разных. Например, мы хотим создать все нужные проекту директории, а их несколько. Вызываем несколько раз задачу mkdir. Она создает директорию, определяемую атрибутом dir:

<target name=”init” description=”Create the needed directories”>

   <mkdir dir=”bin”/>

   <mkdir dir=”lib”/>

<target>

При вызове цели init у нас будут созданы 2 директории — ”bin” и ”lib”.

Возможно, нам надо не только создать директорию, но и подложить в нее какой-то файл. Тогда задачи будут разные.

<target name=”init” description=”Create the needed directories”>

   <mkdir dir=”bin”/>

   <mkdir dir=”lib”/>

   <copy file=”test.jar” todir=”lib”/>

<target>

Стандартная версия Ant содержит более 150 заданий. Вот некоторые из них:

• echo – вывод сообщений в консоль

• mkdir – создание директорий

• copy — копирование файлов

• delete – удаление файлов и директорий

• move – перемещение файлов и директорий

• replace — замещение фрагментов текста в файлах

• javac – компиляция Java–кода

• java – запуск class и jar файлов

• jar – создание jar файла

• junit – запуск тестов

• exec — выполнение внешней команды

• zip — создание архива в формате Zip

Доп ссылки

Writing a Simple Buildfile — официальная дока на английском

Apache Ant – быстрый старт — статья на Хабре

Apache Ant — википедия

Сборка Java приложения, ant

Как запустить сборку

Все зависит от сборщика. Но обычно это название сборщика + название цели, которую мы запускаем. Для Ant это выглядит так:

ant name_of_target

Целей может быть несколько:

ant name_of_target_1 name_of_target_2 name_of_target_3

Фишка ant в том, что вы можете назвать цель как угодно:

ant pupsik

ant mario

ant iron_man

…

С одной стороны, это звучит даже забавно:

— Запускайте Марио!

И все вокруг знают, что это означает пересобрать проект… Но такие хиханьки-хаханьки хороши лишь в умеренных дозах. Подумайте сами — если каждую цель назвать как-то «невпопад», то придется просто заучивать эти названия. Что неудобно.

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

Поэтому обычно используют стандартные названия целей

• clean — чистка проекта: удаление файлов заготовок, которые остаются после компиляции. Приводит проект к виду, в котором он хранится в репозитории

• compile — компиляция исходного кода

• test — запуск тестов

• install — установка пакетов в локальный репозиторий, чтобы использовать зависимости от других проектов локально

• …

Посмотрим на примере, который можно взять и пощупать — в проекте folks используется сборщик maven. А в статье «Как собрать проект и запустить тесты» (в старой версии, там возникли проблемки со сборщиком после обновления и команды заменили) мы видим такие команды:

mvn clean install -Dmaven.test.skip=true -U

mvn clean test

Эти команды — типовые для maven-а. Давайте разберемся, что они означают.

mvn

Это сокращение от maven. Название сборщика, к которому мы обращаемся.

Первое слово, которое вы пишете в командной строке — это вызов команды. Это может быть путь к самой программе вида:

D:allpairspictpict.exe

А может быть просто название команды:

pict

mvn

В этом случае система (я говорю про винду) полезет в PATH и проверит: а есть ли там такое? Если есть, то запустит программу и по короткой команде. Подробнее про PATH можно почитать здесь.

Когда вы устанавливаете maven (ant или любой другой сборщик), вы прописываете путь к нему в переменную PATH. По крайней мере, в инструкции по установке есть такой пункт. Именно благодаря этому пункту команда «mvn» в командной строке начинает работать.

По сути, тут все то же самое, что и в ant — мы пишем название сборщика (mvn) и те цели, которые мы хотим запустить. Точнее, фазы. В maven это называется phases, и набор фаз вполне определенный. В этом отличие сборщиков, ant более гибкий и цели мы можем настраивать и называть так, как захотим. В maven не можем.

clean

В обеих командах сначала вызывается фаза clean. Она нужна для того, чтобы очистить созданные другими сборками артефакты. Так как я тестировщик, то объясню с точки зрения тестирования.

Допустим, мы запускаем автотесты. Их можно запускать пачкой (вообще все или из конкретной папки), а можно запускать один конкретный. Во время прогона система создает артефакты — это может быть состояние базы данных или поискового индекса, временные файлики, или что-то еще.

Теперь, когда мы просто запускаем тест, без clean, система переиспользует созданные артефакты. И это хорошо! Потому что так тесты гоняются намного быстрее. Система уже не тратит время на повторное создание артефактов.

Это как если у вас перед готовкой пустой холодильник или полный. Если пустой — надо идти в магазин. Если вы уже вчера туда сходили и продукты все есть, можно сразу приступать к готовке!

Да, переиспользование артефактов — это хорошо. Но иногда их надо почистить. Вот, скажем, если у вас яйца протухли, то и омлет станет отравой, и шарлотку есть будет нельзя. Любое блюдо будет испорчено из-за одного плохого ингредиента. Баг в исходнике «сломал» готовый продукт!

Что мы делаем в таком случае? Испорченные яйца выкидываем, идем в магазин за новыми. Примерно так и работает clean — чистит наш холодильник. Единственная проблема — она чистит всё. Удалять так удалять!

Фаза удаляет все артефакты, созданные предыдущими сборками. То есть система возвращается в состояние на момент забора данных из репозитория. Плюс твои локальные изменения кода (именно исходного кода, а не сгенеренных по нему артефактов).

Фазу можно и не вызывать, но это надо делать с полным осознанием своих действий. Чтобы потом не тупить над тем, почему это вдруг разработчик исправил баг и у него все хорошо, а у вас до сих пор плохо.

Понимаете, часто повторяющиеся действия мы делаем на автомате, не задумываясь о них. Допустим, что мы привыкли утром очищать свой репозиторий и прогонять

mvn clean install

А потом, в процессе дня, мы фазу clean уже не вызываем:

mvn install

mvn test

...

Так вот, в коде обнаружился баг, который из кода «переехал» в артефакты. Разработчик баг исправил, даже проверил у себя локально — работает! Отдает вам, вы пересобираете проект — не работает! Как так?? Вы же пересобрали! Ведь вызвали же фазу «install».

При этом иногда над простыми ошибками тупят дольше всего. Разработчик снова ковыряется в коде, тратит время — должно же работать. Вы снова собираете — нет, не работает! И только когда разработчик приходит посмотреть, что именно вы делаете, он обращает внимание на команду:

— Стой! Ты же clean не делаешь!

— Ну да, я его только по утрам вызываю…

Это называется «делать на автомате», не задумываясь о своих действиях. Если вы не хотите думать над командой по сборке, то всегда вызывайте clean, не прогадаете. Да, сборка чуть дольше будет идти, но вы точно не огребете такую проблему.

Аналогичная ситуация может возникнуть при прогоне автотестов. Прогнали один тест — все хорошо, он работает. Прогоняете другой — он падает, причем очень странно. Тест пишет, что ожидает «Иванова», которого в вашем тесте нет вообще! Откуда же он взялся??

Да просто первый тест не почистил базу за собой! И Иванов остался в артефактах. А вы не вызвали фазу clean для экономии времени. Отсюда и баг. Поэтому при подозрительных падениях тестов из серии «откуда он взял эти данные» стоит перепрогнать тест с фазой clean.

install

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

1. Скачали исходный код продукта

2. Выполнили команду «mvn clean install»

3. Забрали готовый билд в определенной папочке!

Хотя по сути своей фаза install ничего не собирает. Она публикует собранный артефакт в локальном репозитории. Смотрите — в maven есть свой жизненный цикл (подробнее см в статье «Maven in 5 Minutes», раздел «Maven Phases»):

• validate

• compile

• test

• package

• integration-test

• verify

• install

• deploy

И когда вы вызываете какую-то команду, maven идет по своему жизненному циклу и выполняет все, что идет перед вызванной фазой:

• Вызвали compile — система выполнит validate, а потом compile.

• Вызвали test — система выполнит validate, compile, а потом уже test.

Таким образом, когда мы вызываем install, система на самом деле выполняет кучу других фаз. В том числе и package, который собственно собирает артефакт (jar-файл, war-файл, или что-то еще).

-Dmaven.test.skip=true

Это свойство, которое помогает пропустить тесты во время выполнения вызванной фазы. В нашем случае вызывается:

mvn clean install -Dmaven.test.skip=true

Это означает, что мы хотим собрать проект, не прогоняя при этом тесты. В большом проекте, где много тестов, именно так и делают. Потому что есть разница:

1. Собрать проект — 2-5 мин

2. Прогнать все тесты — 30+ мин

Если разработчик исправил баг в коде и вам просто нужна свежая сборка, вы собираете ее с флагом -Dmaven.test.skip=true. А система CI при этом прогоняет все автотесты.

У меня на одном из проектов в системе CI задачи были разделены — одна собирает только билд, с флагом -Dmaven.test.skip=true, а вторая честно прогоняет все тесты. И если в коде есть баг, из-за которого даже билд не собирается, мы узнаем об этом через 2 минуты, а не через 32. Удобно =)

-U

Это флаг означает принудительное обновление зависимостей.

Чем больше проект, тем больше там зависимостей. Это могут быть зависимости от каких-то стандартных библиотек, или от других ваших проектов. Вот, скажем, у меня на одной работе было несколько проектов. Чтобы не дублировать код, разработчики создали проект Utils, куда вынесли общие классы, которые никак не привязаны к бизнес логике проекта:

• скопировать директорию;

• распаковать архив;

• и т.д

Проект использует код из Utils. И если разработчик вносил правки в Utils, то наш проект надо собирать обязательно с флагом -U. Иначе изменения не подтянутся и система продолжит работать по старому.

Разработчики используют флаг сознательно. Они ведь меняют код и понимают, нужно обновлять зависимости или нет. А тестировщики в проект Utils обычно не лезут, и за изменениями в нем не следят. Поэтому нас учили так — всегда используй флаг -U, не прогадаешь. И на первом этапе знакомства со сборщиком этого вполне достаточно =)

test

Фаза test запускает автотесты. Причем если запускать без параметров:

mvn clean test

То система прогонит ВСЕ тесты. Разумеется, это не всегда то, что нам надо. Вот, например, у нас в компании 4000 модульных автотестов. Прогоняются они за полчаса. Мне выдали новый функционал на тестирование, я пишу автотесты. Как прогнать только свеженаписанный тест? Чтобы узнать ответ через полминуты, а не полчаса?

Для этого есть параметры:

• -Dtest — запустить Java-класс с тестом. А Java-класс обычно описывает логику автотестов, например — «Внутри этой директории тесты на поиск. Возьми данные из файла с таким названием, положи в базу. Потом возьми вот эту строку и по ней ищи».

• -Dtest.case — запустить конкретный тест-кейс. Это уже точечная проверка: «В базе есть Маша и Ваня, поиск по «Ваня» Ваню вернет, а Машу нет» (это особенность фреймворка folks, а не работа из коробки maven). 

Итого

Для запуска сборки вам надо ввести в командную строку название сборщика + название цели, которую мы хотим выполнить. Иногда цели могут называться как ваша левая пятка того пожелает (ant), а иногда это набор вполне конкретных значений (maven).

Что сборщик умеет делать

1. Компилировать проект

Это самое важное в сборщике. В большинстве случаев нам нужно, чтобы при помощи одной команды делалось всё — от установки до упаковки проекта в пакеты.

2. Чистить все ненужное

Для этого обычно создают цель clean. Она нужна для наведения порядка после компоновки проекта — удаляет директории, созданные по ходу процесса компоновки, или артефакты тестирования.

3. Выводить информацию о проекте

Гуглить — это, конечно, хорошо. Но не всегда помогает. Для maven вы можете нагуглить команду сборки, а как быть с Ant? Что, если коллеги назвали цель сборки «SuperMario»? В сборщике должен быть:

• Мануал — информация о том, как его использовать.

• Информация о проекте — список доступных целей, описание каждой и цель, установленная по умолчанию.

В Ant для вывода информации о проекте достаточно напечатать команду:

ant -projecthelp

4. Обращаться к библиотекам, используемым в проекте

Это только на очень небольшом самописном проекте можно обойтись без сторонних библиотек. Да и то придется городить костыли и придумывать велосипеды. А зачем, когда есть готовые библиотеки? Сборщик должен уметь с ними общаться.

В Ant можно добавить библиотеки в путь компоновки, используя элемент «classpath» в задаче «javac»:

<javac srcdir=”src” destdir=”bin”>

  <classpath>

     <pathelement location=”libs/junit.jar”>

     <pathelement location=”libs/log4j.jar”>

  </classpath>

</javac>

В данном примере мы подключаем к проекту 2 библиотечки:

• junit — для автотестов;

• log4j — для логирования;

Каждый элемент пути (pathelement) указывает на добавление отдельного jar-файла. Но можно указать на директорию со внешними библиотеками.

Также сборщики умеют загружать библиотеки при помощи FTP, HTTP, SCP и т.д.

5. Запускать приложение

Запуск приложения может оказаться нетривиальной задачей. Например, для этого нужно прописать ряд переменных в разных файлах, или много разных опций в командной строке. Человек ошибается, робот — нет. Отдайте ему эту работу.

6. Запускать тесты

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

Но если автотесты есть, сборщик должен уметь их запускать. Именно это мы и делаем в folks — пишем команду:

mvn clean test

И уже сборщик (maven) запускает прогон автотестов.

7. Другие задачи

Еще несколько примеров того, что может делать сборщик:

• Брать код для внесения исправлений

• Копировать компоновку в архивные директории

• Шифровать файлы

• Высылать сообщения на эл почту, когда закончена компоновка

• Запускать SQL

• …

Автоматизация позволяет сфокусироваться на коде, а не на повторяющихся задачах. С хорошим скриптом компоновки мы можем автоматизировать этот крайне сложный процесс.

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

Где хранить скрипт компоновки

Скрипт компоновки — это тоже код. Так что положите его в систему контроля версий.

Теперь, если на проект придет новый разработчик, у него не будет проблем! Выкачал из системы контроля версий исходный код и скрипт компоновки, прочитал скрипт и запустил нужную опцию!

Программы сборки

Для java — Ant, Maven, Gradle

.Net — NAnt

Ruby — rake

В Microsoft Visual Studio – MSBuild

При использовании Perl или PHP скрипты компоновки не так полезны. Но можно использовать инструмент для компоновки, даже если нужны не все его функции.

Как выбрать программу для сборки

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

Иногда можно вообще обойтись с помощью командного файла. Ну а что, прописать всё те же команды через bash — создай файл, удали директорию… Но в системах компоновки есть много специальных задач, ориентированных на разработку. И в командном файле их придется писать самому. А зачем, когда есть готовое решение?

В статье я приводила примеры по двум инструментам для Java-проектов — Ant и Maven. Как выбрать из них?

Ant — очень простой инструмент компоновки. Может компилировать код, создавать и удалять директории, группировать файлы. Ant ничего не знает о жизненном цикле продукта. Он просто выполняет те задачи, которые вы пропишете в скрипте компоновки.

Однако Ant сейчас лучше не использовать. Он совсем устаревший, да и в нем нет из коробки поддержки зависимостей. Его используют на проектах, где «так повелось», где он был исходно. Ну или фриланс-разработчики, которые делают совсем небольшой проект.

У нас на  одном из проектов был Ant. В целом, свои функции он выполнял. Все скрипты уже давно написаны, так что жили по принципу «Работает? Не трогай».

С другой стороны, делать что-то новое намного сложнее, чем на более гибких инструментах. В итоге переехали на gradle. Да, переезд занимает время, но оно окупается, как и любой рефакторинг.

Maven — более многофункциональный инструмент. Он знает про жизненный цикл продукта. Знает, что и в каком порядке нужно делать. И умеет кучу всего, что Ant не делает:

• автоматическое извлечение зависимостей в библиотеке;

• автоматизация тестирования;

• и т.д.

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

К тому же для любого действия maven «выкачивает полинтернета», как называют это мои коллеги. Ну да, он умеет автоматически извлекать зависимости. И он будет это делать, даже если вам надо прогнать один небольшой автотестик!

Чтобы выжать их Maven максимум, проект нужно структурировать определенным образом. Пример можно посмотреть все в том же folks. Эта структура:

• main

• test

То есть когда у тебя есть «главная» папка проекта или какого-то модуля, а в ней отдельно код, отдельно тесты — это как раз структура, которую требует maven. И намного проще писать проект под maven c нуля, чем переписывать уже существующий. Миграция — это жизньболь.

Gradle — более гибкий, позволяющий легко на языке  программирования (groovy/kotlin) дописать сложную логику сборки

При работе с небольшими проектами Ant обеспечит весь необходимый функционал. И проще выбрать его. Если нужно больше возможностей, осознанно выбираем Maven. Если нужно больше возможностей, но что-то погибче, тогда смотрим на Gradle.

Итого по выбору

Как выбрать — вопрос неоднозначный. В принципе, если команда уже освоила какой-то сборщик и он всех устраивает, то его можно и использовать.

• maven более декларативный и простой (требует только понимания xml)

• gradle более гибкий, позволяющий легко на языке  программирования (groovy/kotlin) дописать сложную логику сборки, но скорее всего среди энтерпрайза встречается реже

• ant лучше не юзать уже, он устаревший, да и в нем нет из коробки поддежки зависимостей

Итого

Когда разработчик пишет код — он просто создает набор файликов с текстом. Чтобы эти файлики превратились в работающее приложение, нам нужно выполнить ряд действий:

• скомпилировать проект;

• объединить классы в файл JAR или другую библиотеку;

• установить набор зависимостей;

• запустить конкретный класс или несколько классов.

И только после всех этих манипуляций у нас появляется ПО. Набор манипуляций зависит от конкретного проекта.

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

ant install

Сборщик можно запустить из командной строки, на любом окружении, независимо от среды разработки + в CI/CD системе (TeamCity, Jenkins и тп).

См также:

Управление разработкой ПО. Дэн Пилон, Расс Майлз — отличная книга о процессе разработки, в том числе и о сборщиках там есть

Другие статьи из цикла «Что такое…»

Что такое VCS (система контроля версий)

Что такое API

Что такое XML

Что такое JSON

Что такое клиент-серверная архитектура

Что такое CI (Continuous Integration)

Что такое транзакция

Что такое регулярные выражения (regexp)

Что такое Docker

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Вступление

C ++, как и C, имеет долгую и разнообразную историю, связанную с процессами компиляции и процессами сборки. Сегодня C ++ имеет различные популярные системы сборки, которые используются для компиляции программ, иногда для нескольких платформ в рамках одной системы сборки. Здесь будут рассмотрены и проанализированы несколько систем сборки.

замечания

Создание среды сборки с помощью CMake

CMake создает среду сборки практически для любого компилятора или IDE из одного определения проекта. В следующих примерах показано, как добавить файл CMake в кросс-платформенный код «Hello World» C ++ .

Файлы CMake всегда называются «CMakeLists.txt» и должны уже существовать в корневом каталоге каждого проекта (и, возможно, в подкаталогах тоже). Основной файл CMakeLists.txt выглядит так:

cmake_minimum_required(VERSION 2.4)

project(HelloWorld)

add_executable(HelloWorld main.cpp)

Смотрите на живую в Колиру .

Этот файл сообщает CMake имя проекта, какую версию файла ожидать и инструкции для создания исполняемого файла под названием «HelloWorld», для которого требуется main.cpp .

Создайте среду сборки для вашего установленного компилятора / IDE из командной строки:

> cmake .

Создайте приложение с помощью:

> cmake --build .

Это создает среду сборки по умолчанию для системы, в зависимости от ОС и установленных инструментов. Держите исходный код в чистоте от любых артефактов сборки с использованием «внекорпоративных» сборников:

> mkdir build
> cd build
> cmake ..
> cmake --build .

CMake также может абстрагировать основные команды платформы оболочки из предыдущего примера:

> cmake -E make_directory build
> cmake -E chdir build cmake .. 
> cmake --build build 

CMake включает в себя генераторы для ряда общих инструментов сборки и IDE. Чтобы создать make — nmake для nmake Visual Studio :

> cmake -G "NMake Makefiles" ..
> nmake

Компиляция с 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

# Set some variables to use in our command
# First, we set the compiler to be g++
CXX=g++

# Then, we say that we want to compile with g++'s recommended warnings and some extra ones.
CXXFLAGS=-Wall -Wextra -pedantic

# This will be the output file
EXE=app

SRCS=main.cpp

# When you call `make` at the command line, this "target" is called.
# The $(EXE) at the right says that the `all` target depends on the `$(EXE)` target.
# $(EXE) expands to be the content of the EXE variable
# Note: Because this is the first target, it becomes the default target if `make` is called without target
all: $(EXE)

# This is equivalent to saying
# app: $(SRCS)
# $(SRCS) can be separated, which means that this target would depend on each file.
# Note that this target has a "method body": the part indented by a tab (not four spaces).
# When we build this target, make will execute the command, which is:
# g++ -Wall -Wextra -pedantic -o app main.cpp
# I.E. Compile main.cpp with warnings, and output to the file ./app
$(EXE): $(SRCS)
    @$(CXX) $(CXXFLAGS) -o $@ $(SRCS)

# This target should reverse the `all` target. If you call
# make with an argument, like `make clean`, the corresponding target
# gets called.
clean:
    @rm -f $(EXE)

ПРИМЕЧАНИЕ. Убедитесь, что отступы имеют вкладку, а не четыре пробела. В противном случае вы получите сообщение об ошибке Makefile:10: *** missing separator. Stop.

Чтобы запустить это из командной строки, выполните следующие действия:

$ cd ~/Path/to/project
$ make
$ ls
app  main.cpp  Makefile

$ ./app
Hello World!

$ make clean
$ ls
main.cpp  Makefile

Инкрементальные сборки

Когда вы начинаете иметь больше файлов, make становится более полезным. Что делать, если вы отредактировали файл a.cpp, но не b.cpp ? Перекомпиляция b.cpp займет больше времени.

Со следующей структурой каталогов:

.
+-- src
|   +-- a.cpp
|   +-- a.hpp
|   +-- b.cpp
|   +-- b.hpp
+-- Makefile

Это будет хороший Makefile:

Makefile

CXX=g++
CXXFLAGS=-Wall -Wextra -pedantic
EXE=app

SRCS_GLOB=src/*.cpp
SRCS=$(wildcard $(SRCS_GLOB))
OBJS=$(SRCS:.cpp=.o)

all: $(EXE)

$(EXE): $(OBJS)
    @$(CXX) -o $@ $(OBJS)

depend: .depend

.depend: $(SRCS)
    @-rm -f ./.depend
    @$(CXX) $(CXXFLAGS) -MM $^>>./.depend

clean:
    -rm -f $(EXE)
    -rm $(OBJS)
    -rm *~
    -rm .depend

include .depend

Снова посмотрите вкладки. Этот новый Makefile гарантирует, что вы только перекомпилируете измененные файлы, минимизируя время компиляции.

Документация

Для получения дополнительной информации см. Официальную документацию Free Software Foundation , документацию по стеку и подробный ответ dmckee на stackoverflow .

Строительство с помощью SCons

Вы можете построить кросс-платформенный код «Hello World» C ++ , используя инструмент разработки программного обеспечения Scons — A Python- language.

Сначала создайте файл SConstruct (обратите внимание, что SCons будет искать файл с этим точным именем по умолчанию). На данный момент файл должен находиться в каталоге прямо по вашему hello.cpp . Напишите в новом файле строку

 Program('hello.cpp')

Теперь, с терминала, запустите scons . Вы должны увидеть что-то вроде

$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o hello.o -c hello.cpp
g++ -o hello hello.o
scons: done building targets.

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

Классы Environment и Glob помогут вам настроить конфигурацию. Например, файл SConstruct

env=Environment(CPPPATH='/usr/include/boost/',
    CPPDEFINES=[],
    LIBS=[],
    SCONS_CXX_STANDARD="c++11"
    )

env.Program('hello', Glob('src/*.cpp'))     

создает исполняемый 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 Build System для данного программного пакета. Это набор инструментов, которые работают вместе для создания различных ресурсов сборки, таких как Makefile (для использования с GNU Make). Таким образом, Autotools можно считать генератором системы де-факто.

Некоторые известные программы Autotools включают в себя:

• Autoconf
• Automake (не путать с make )

В общем, Autotools предназначен для создания Unix-совместимого скрипта и Makefile, чтобы позволить следующей команде создавать (а также устанавливать) большинство пакетов (в простом случае):

./configure && make && make install

Таким образом, Autotools также имеет отношение к определенным менеджерам пакетов, особенно к тем, которые подключены к операционным системам, которые соответствуют стандарту POSIX.

Но если даже такой вопрос на ум не приходил, то наверняка многих после установки проблемной сборки посещало желание рассказать её горе-сборщику, что они о нём думают, и куда тому нужно идти. Так называемые облегчённые сборки – дистрибутивы с вырезанным или отключённым функционалом, предназначенные для маломощных компьютеров, оптимизированные для игр или прочих специфических задач, по части быстродействия редко когда ощутимо отличаются от обычных дистрибутивов. Зато такие сборки точно доставят проблем, когда понадобятся отсутствующие функции Windows. Как говорится, хочешь, чтобы было всё нормально – сделай дело сам. Ниже рассмотрим, как создаются модифицированные сборки системы с каким-то удалённым, а каким-то добавленным функционалом. И попытаемся собрать свой дистрибутив Windows с помощью программы NTLite.

Зачем создавать свои сборки Windows

В , в принципе, нет ничего плохого. Но лишь при условии, что вырезана действительно ненужная часть дистрибутива, и система остаётся работоспособной по части взаимодействия с аппаратной начинкой и предоставлении доступа к основному функционалу. На 100% угадать, что нужно вырезать, а что оставить в системе, для большой аудитории, естественно, не получится. Но сделать это для себя, для пары-тройки имеющихся в доме компьютерных устройств можно. Для этого нужно точно знать, какой системный функционал никогда не пригодится. А, следовательно, необходимо хотя бы поверхностно разбираться в нём – какие компоненты и службы для чего нужны, что решают те или иные настройки Windows. Но это если вырезать функционал.

Делать первые шаги на поприще создания модифицированных сборок Windows можно ведь и без вырезания функционала системы. А, наоборот, с расширением её возможностей — с добавлением драйверов комплектующих (и даже периферии), с установкой полезных программ. Собственно, для этих целей и существует специальный софт типа NTLite.

О программе NTLite

Программа NTLite – это инструмент для создания модифицированных сборок Windows. Она позволят вырезать из дистрибутива определённый функционал, отключать системные службы, задавать определённые системные настройки, внедрять драйверы, обновления, твики реестра, сторонние программы. Она не является способом создания сборок с предустановленным сторонним софтом, как, например, подготовка Windows к развёртыванию в режиме аудита. Но NTLite – это мощнейший твикер дистрибутива с возможностью применения инструмента Post-Install для автоматического запуска процесса установки добавленных в такой дистрибутив сторонних программ.

NTLite — платная программа, перед покупкой лицензии можно опробовать её триал-версию на сайте

Home

Ну а теперь приступим непосредственно к созданию сборки. С помощью этой программы мы распакуем установочный образ Windows, проведём его настройку, а затем снова запакуем в пригодный для установки формат.

Распаковка исходника

Первым делом подготовим исходный ISO-образ с процессом установки Windows 7, 8.1 или 10. Либо монтируем ISO-файл для отображения в проводнике.

А затем копируем всё содержимое установочного диска в отдельную рабочую папку.

Либо извлекаем содержимое ISO с помощью архиватора. Кому как удобнее.

Добавление исходника

Запускаем программу NTLite. В её окне жмём «Добавить» и указываем путь к рабочей папке, куда мы скопировали (или распаковали) на предыдущем этапе содержимое ISO-исходника.

Увидим структуру компонентов этого ISO, в числе которых будут редакции той или иной версии Windows. Нам нужно выбрать одну из них. Все проделанные в дальнейшем настройки теперь будут касаться только выбранной редакции, и только она одна будет содержаться в модифицированном дистрибутиве, который мы получим по итогу проделанной работы. Выбираем редакцию, вызываем на ней контекстное меню, жмём «Загрузить». Если мы работаем с дистрибутивом Windows 8.1 и 10, нужно ещё дополнительно подтвердить операцию конвертирования образа из формата WIM в ESD.

NTLite проводит операции с WIM-образами – файлами install.wim, в которых содержатся установочные файлы Windows. И ESD-образы – сжатые файлы install.esd, в которых хранится дистрибутив версий системы 8.1 и 10 – программа в процессе загрузки будет преобразовывать в WIM-формат. Конвертирование образов из ESD в WIM – процедура небыстрая, придётся подождать. С образами Windows 7 в этом плане намного проще, поскольку они изначально существуют в WIM-формате. Так что, друзья, знакомство с возможностями NTLite лучше начать с создания модифицированных сборок «Семёрки». В таком случае не придётся конвертировать образ ни изначально из WIM в ESD, ни наоборот по завершении подготовки сборки для её упаковки в ISO.

• Примечание
  : в процессе конвертирования образа из ESD в WIM на слабых и усреднённых компьютерах может подгружаться процессор. В таком случае можно на время отключить защиту в реальном времени Защитника Windows или стороннего антивируса.
  

Когда WIM- или ESD-образ загрузится в окно программы NTLite, увидим сообщение об этом возле выбранной редакции. Также обнаружим, что на панели слева, кроме текущей вертикальной вкладки «Исходник», появилась масса других вкладок. Исследуем их по очереди. Переходим на вкладку «Компоненты».

Компоненты, функции и службы Windows

Во вкладке «Компоненты» можно отключать, соответственно, те или иные компоненты системы, снимая их галочки. Что здесь можно отключить? Аппаратную поддержку отдельных периферийных устройств типа модемов, ИК- и Bluetooth-модулей, смарт-карт и т.п., а также драйверы комплектующих, которые точно не будут подключены к тому ПК или ноутбуку, для которого готовится сборка. Также можно отключить такие компоненты как:

Языки и раскладки клавиатуры;

DVD-проигрыватель и мастер записи оптических дисков;

Утилиты «Ножницы», «Заметки», «Диктофон», «Запись действий»;

Распознавание речи, экранную клавиатуру;

Штатный Skype;

Сетевые компоненты;

Центр мобильности;

Защитник Windows;

Если стоит задача уменьшить вес самого дистрибутива, можно ориентироваться на отображаемый в последнем столбце таблицы вес компонентов. Компоненты Windows – это тот её функционал, который вырезается, а не отключается. Не все вырезанные из дистрибутива компоненты можно будет потом беспроблемно скачать в Интернете и внедрить в систему. Так что, проводя настройки во вкладке «Компоненты», нужно очень аккуратно обращаться со снятием галочек.

Во вкладке ниже «Функции» подобраны функции Windows, которые не вырезаются, но они могут быть отключены в дистрибутиве по умолчанию. Или, наоборот, включены, тогда как в официальном образе от Microsoft отключены. Как, например, NET Framework 3.5 или службы IIS. Из числа предустановленных функций отключить можно, если не будут использоваться:

Гаджеты Windows 7;

Штатные офисные игры («Косынка», «Паук», «Солитер» и т.п.);

Windows Media Center, проигрыватель Windows Media, DVD-студию, компоненты планшетного ПК;

Подсистему Linux;

Службы XPS и PDF-принтер;

Индексацию и внутрисистемный поиск;

• Примечание
  : NTLite может предложить даже отключение Internet Explorer, однако делать этого не стоит. Отключение Internet Explorer может вызвать сбой в работе других приложений системы.

Чтобы отключить ту или иную функцию, необходимо убрать её галочку. Чтобы включить, галочку нужно установить.

Вкладка «Службы» позволяет отключить неиспользуемые службы Windows. Или, наоборот, включить те, что отключены по умолчанию. Для выбранной службы из выпадающего перечня в конце строки необходимо выбрать нужное значение, например, «Отключено».

Службы Windows – ещё один важный этап настройки дистрибутива, где нужно не переборщить с отключением. Без автозапуска определённых служб Windows может попросту не запустится. Тут нужно также чётко понимать, что и зачем мы отключаем.

Настройки

Во вкладке «Локальный компьютер» собраны некоторые системные настройки типа задания параметров файла подкачки, UAC, Центра обновлений и т.п. Задаются настройки либо выставлением положения «Включено/Отключено», либо указанием конкретных данных, как в случае с файлом подкачки.

Вкладка «Пользователи» — нечто лёгкого твикера для тонкой настройки юзабилити системы.

Обновления, драйверы, твики реестра

Во вкладке «Обновления» можем просмотреть перечень уже интегрированных в исходный дистрибутив обновлений, а также добавить новые пакеты обновлений.

Вкладка «Драйверы» служит для добавления, соответственно, драйверов. Нажав кнопку «Добавить», сможем указать программе NTLite папку с подборкой драйверов для конкретного устройства. Или, например, интегрировать в процесс установки Windows 7 универсальные драйверы USB 3.0.

Интересно, что при работе в той же версии системы и на том же компьютере, для которых и сборка готовится, можно не искать диски с драйверами, не скачивать их с официальных сайтов, а импортировать из текущей системы. Для этого необходимо нажать кнопку «Импортировать текущую ОС», а когда драйверы подгрузятся – кнопку «Исключить неиспользованные».

Если у нас есть какие-то твики системного реестра — REG-файлы с теми или иными настройками, можем и их внести в состав дистрибутива. И эти твики будут применены на этапе предварительной настройки системы вместе с установкой драйверов. В нашем случае, например, добавлен REG-файл смены метода масштабирования Windows 10 на тот, что был в версии 8.1.

Персонификация

Во вкладке «Автоматическая», если сборка делается для себя, можно установить некоторые персональные настройки как то:

Язык, часовой пояс;

Имя компьютера, ключ активации;

Настройки сети;

И тогда эти этапы установки пройдут автоматически. Эти настройки задаются выбором нужного значения в выпадающем списке или установкой положения «Истина/Ложь».

Установка сторонних программ

Вкладка «После установки» — это настройка функции Post-Install, череды автоматически запускающихся процессов инсталляции стороннего ПО. Внедрение софта в сборку Windows хоть в виде уже установленных программ, хоть в виде Post-Install — спорное улучшение, если мы говорим о компьютерах обычных пользователей. Версии программ быстро устаревают, и такие доработки, естественно, увеличивают вес дистрибутива. Тем не менее несколько программ-завсегдатаев типа браузера, архиватора, файлового менеджера внедрить можно. Функция Post-Install, реализованная программой NTLite, запускается на завершающем этапе предварительной настройки Windows. И на этом этапе — без интерфейса системы, без активности лишних служб и драйверов — установка программ проходит очень быстро.

• Примечание
  : друзья, если по причине внедрения стороннего софта ISO-образ установки Windows выйдет более 4 Гб, записать его на флешку для компьютеров с BIOS UEFI, которая должна быть отформатирована в FAT32, поможет утилита WinSetupFromUSB. Она предусматривает механизм обхода ограничений FAT32.

С помощью кнопки «Добавить» добавляем инсталляторы программ для Post-Install. В графе «Параметры» при желании для программ, которые не предусматривают попутной установки всякого хлама, можно указать их ключи тихой установки.

Когда все настройки будут произведены, можем жать внизу «Применить».

Упаковка модифицированной сборки в образ

Итак, модифицированный дистрибутив настроен, но ещё не готов. Все операции пока что только запланированы. Их нужно применить, а сам дистрибутив упаковать в образ.

WPI (Windows Post Install)
— это оболочка
, в которой мы выбираем программы для инсталляции и после нажатия на кнопку “УСТАНОВИТЬ” установка
проходит полностью в тихом режиме
, т.е. не выдавая никаких сообщений
пользователю в стиле “Нажмите далее”. Это существенно сокращает время
настройки операционной системы, поэтому мы воспользуемся данной технологией. Чтобы не изобретать велосипед, мы не будем создавать WPI сборку с нуля, а разберёмся в принципе работы этой оболочки на примере уже существующей сборки, но данных знаний нам будет достаточно, чтобы создать собственную сборку с нуля.

Шаг 1.
Скачиваем (скачать) и копируем папку WPI
в папку SystemFlash.

Шаг 2.
В папке SystemFlashWPIUserFiles
переименовываем файл useroptions
в

Шаг 3.
Запускаем SystemFlashWPIWPI.exe
и видим что слева появились дополнительные кнопки.

Шаг 4.
Заходим в Настройка WPI-Общие
и убираем галочку с Таймера обратного отсчета
, затем жмём Сохранить-Выход.

Шаг 5.
Мы получили доступ в режим конфигурации WPI. Жмём на кнопку и смотрим какие вкладки за что отвечают.

Шаг 6.
Удаляем ненужные приложения и меню. Для этого заходим в конфигурацию программ
и выбираем программу (в примере я удалю NET Framework, т.к. он и так уже есть в нашей сборке Windows 7).

class=»eliadunit»>

Шаг 7.
Затем переходим в и смотрим где располагается наша программа.

Шаг 8.
Находим её в папке WPIInstall
и удаляем.

Шаг 9.
Переходим на вкладку Tool Tips
и смотрим где располагается файл с рисунком.

Шаг 10.
Находим его в папке WPIGraphicsLogos
и удаляем.

Шаг 11.
Возвращаемся к WPI. Жмём Удалить-Да.

Таким методом удаляем все программы, которые нам не нужны.

Свести к минимуму время и силы на процесс переустановки Windows можно, если:

• Использовать актуальную версию системы 10, которая в большинстве случаев сама поставит драйверы как минимум на значимые комплектующие;
• Использовать свежайший дистрибутив, и тогда не нужно будет возиться с обновлениями системы;
• Хранить в одной какой-то папке инсталляторы сторонних программ, чтобы не вспоминать их и не бегать по сайтам их разработчиков для скачивания;
• С частью программ и вовсе работать в их портативных версиях;
• Использовать сервисы синхронизации браузеров, экспортировать-импортировать настройки программ.

Ещё один, не совсем однозначный способ упрощения переустановки Windows – создание собственной сборки с интегрированным софтом. Однако если такую сборку не обновлять периодически, после переустановки система может надолго подвиснуть в обновлениях. Да и софт, который не обновляется автоматически, придётся затем вручную освежать.

Оптимальным вариантом всё же будет установка системы из чистого свежего дистрибутива. А нужные программы по-быстренькому можно установить с помощью специального типа ПО – мультиустановщиков. Рассмотрим некоторые из них.

Мультиустановщики для пакетной инсталляции программ в Windows

1. InstallPack

https://installpack.net

Бесплатная портативная утилита InstallPack – простейший способ пакетной установки Windows-программ. Их инсталляторы берутся с официальных сайтов разработчиков и периодически освежаются. В окне InstallPack доступный для пакетной установки софт каталогизирован, есть краткие описания и рейтинг. Чтобы установить нужные программы, ставим их галочки и жмём «Далее».

Затем снимаем галочки с продуктов, продвигаемых самой InstallPack.

На предфинальном этапе пошагового мастера увидим прогресс скачивания выбранного софта. InstallPack предлагает лишь частичную автоматизацию инсталляции, режим «тихой установки» не поддерживает. Потому отдельные установочные этапы программ нужно пройти вручную.

С одной стороны, неполная автоматизация — это минус. Но если есть необходимость в выборе отличного от дефолтного пути установки программ, то это, наоборот, плюс. По завершении сессии пакетной установки софта либо возвращаемся в начало и что-то доустанавливаем, либо завершаем работу с InstallPack.

InstallPack внедряет в систему только лицензионное ПО.

2. Ninite

https://ninite.com/

Ninite – специфический пакетный установщик, это бесплатный веб-сервис. Выбор конкретных программ для пакетной установки осуществляется на сайте проекта.

Затем сервис генерирует мультиинсталлятор со всеми выбранными программами и предлагает его скачать.

Скачиваем, запускаем и дожидаемся завершения установки софта. Ninite работает в «тихом режиме». Лишь в отдельных окошках пакетного установщика будем наблюдать отчёт о проводимом процессе и его прогрессе.

Ninite – англоязычный веб-сервис, но если в Windows главным языком является русский, программы, поддерживающие русскоязычную локализацию, по умолчанию установятся именно на нашем языке. Ninite работает честно, потому в каталоге софта сервиса найдём только бесплатные продукты.

3. Npackd

https://npackd.appspot.com/

Npackd – бесплатный мультиустановщик с огромнейшей базой лицензионного Windows-софта. Включает возможность установки не только офисных, мультимедийных, различных обывательских программ, но также системных компонентов и программных платформ для разработчиков. Может устанавливать, обновлять и даже удалять программы из системы, причём всё это в пакетном режиме. Npackd оперирует свежайшими инсталляторами программ, доступные для установки их версии значатся в отдельной графе табличного перечня в главном окне мультиустановщика. А в контекстном меню есть пункт отправки на официальный сайт разработчиков ПО.

Чтобы запустить пакетную установку, нужно кликнуть нужные программы в перечне окна Npackd, удерживая клавишу Ctrl. Затем нажать кнопку «Установить» и подтвердить запуск инсталляции.

Прогресс операции будет отображаться во вкладке «Задание».

Но добавлять все программы в единый процесс инсталляции не обязательно. Npackd – не пошаговый мультиустановщик, можно спокойно просматривать перечень софта и кликать кнопку «Установить» для каждой отдельной программы. Таким образом она добавится в перечень заданий и установится тогда, когда нужно, в «тихом режиме».

Одна из специфик работы Npackd – отказ установки 32-битных программ в 64-битную Windows. В каталоге этого мультиустановщика необходимо подбирать соответствующие редакции ПО.

4. Windows Post Installation

Windows Post Installation, он же сокращённо WPI – это так называемый постустановщик софта в среду Windows. Это не конкретная программа от конкретного разработчика, как те, что представлены выше. Изначально WPI – это платформа для создания сборок установки софта, которую используют сборщики-энтузиасты. Они комплектуют сборники WPI своими подборками софта и выкладывают их в Интернете, в частности, на торрент-трекерах. В составе сборников WPI не всегда присутствуют только бесплатные продукты или триал-версии ПО. Некоторые сборники содержат как лицензионный софт, так и пиратский — взломанные редакции платных программ. Постустановщик WPI иногда присутствует на борту пиратских сборок Windows.

Отдельно (без пиратской сборки Windows) WPI обычно существуют в формате ISO-образов. Их можно записать на DVD-диск и использовать на разных компьютерных устройствах. А можно просто подмонтировать образ для отображения в среде операционной системы и запуска приложения WPI.

What kind of online business without creating an online store? Any sales and your profits can be organized by creating an online store of products or services. The advantage of ordering the development of an online store is that it is much cheaper than building a trading platform in any …

Today, social networks are widely used for business contacts and job search. Employers are increasingly turning to social networks to search for specialists. Do you want your vacancy announcement to be maximized in record time? · post an eye-catching ad(one of the undoubted advantages of this placement is the ability …

If you have your own business and you are wondering where to look for the staff? We have prepared an article that will help simplify the search for employees. Do you know the situation when there were very few responses to the vacancy you have posted? There are two main …

Who is a programmer A programmer is a specialist who creates source code for a program. Such a program can be a computer operating system, a video game, a web or mobile application, and even a microwave operation algorithm. The program code is written in a special programming language. It …

What are the opportunities of promoting a website? There are many possibilities in order to make your site flourished. 1. Guest Posts This is a very powerful tool that works well. For this you need: – find suitable sites for you (websites or blogs) – to offer them material (relevant …

В интернете на сайтах софтверной тематики вам наверняка приходилось встречать сборки программ, распространяемые в виде одного ISO-файла или нескольких каталогов с одним удобным меню инсталляции. Хотите узнать, как делаются такие сборки? Очень просто. Способы есть разные, но мы познакомимся только с одним из них. Для создания собственной сборки мы будем использовать утилиту MInstAll
.

1. О программе

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

Приложением поддерживается добавление к программам сборки описаний, ссылок, иконок из встроенной библиотеки, ключей командной строки, автоматическая проверка на наличие уже установленных на ПК программ, удаление уже добавленных, сортировка по группам, создание исключений, импорт файлов реестра и многое другое.

2. Как работать с MInstAll

Ничего сложного в работе с программой нет. После распаковки архива с утилитой вы получите исполняемый файл AutoRun.exe
, конфигурационный файл AutoRun.ini
, файл контрольных сумм и каталог MInstAll
. В этом каталоге вы найдете ещё несколько файлов и папок. Интерес для нас представляют только две: software
и Portable
. В первую копируем исполняемые файлы программ, которые предполагается устанавливать на ПК, во вторую складываем портативные приложения.

По умолчанию эти папки уже могут содержать какие-то программы, но это не суть важно. Если они не нужны, вы всегда можете удалить их через основное меню утилиты. После того как каталоги software
и Portable
будут укомплектованы, запускаем AutoRun.exe
и приступаем к работе. В выпадающем меню выбираем профиль «Установка приложений
», захватываем мышкой файл программы из папки software
и кидаем его на окошко MInstAll
.

При этом откроется новое окно, в котором вам предстоит заполнить несколько полей. Это необязательно, так как самые главные из них, в частности, путь и название заполняются автоматически, но если вы хотите, чтобы человек, который будет пользоваться вашим набором, не терялся в догадках, советуем внести данные в следующие поля: «Версия
», «Группа
», «Статус
», «Сайт разработчика
», «Совместимость ОС
» и «Описание
».

Дополнительно можно установить путь к иконке. Остальные поля, если не знаете, для чего они нужны, заполнять не надо. Что касается ключей запуска, иногда MInstAll подбирает их сама, в остальных случаях вам придётся указывать их самим, так что рекомендуем поинтересоваться, какой ключ за какое действие отвечает. Точно так же добавляем в меню утилиты и другие приложения. Потом программу и её папки можно записать на диск или флешку, а затем уже выполнять с неё установку программ по отдельности или в пакетном режиме.

Скачать MInstAll можно с сайта разработчика checkdevice.narod.ru . Распространяется утилита бесплатно, поддерживает запуск на всех популярных редакциях ОС Windows. На официальном сайте желающие также могут найти авторскую сборку программ общим весом более 3 Гб.

Помогла ли Вам данная статья?

Учимся компилировать C++ программу -12

Программирование, C++, Блог компании OTUS. Онлайн-образование

---

Рекомендация: подборка платных и бесплатных курсов системной аналитики — https://katalog-kursov.ru/

---

Одна из самых сложных тем, с которыми я столкнулся в начале изучении C++, помимо указателей и управления памятью, заключалась в том, как успешно компилировать код с использованием сторонних библиотек.

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

По крайней мере, у меня были с этим трудности, потому что я просто не понимал, как программы на C++ собираются и распространяются по интернету. Я не понимал, как мой исходный код превращается в исполняемый файл или библиотеку, и не понимал, как компилировать платформо-независимый код.

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

Эти знания не из тех, которые обычно входят в обучающие программы. Основное внимание уделяется решению проблем и синтаксису C++, и, тем не менее, если вы хотите заниматься серьезным программированием игр на C++ без написания всего с нуля, эти знания необходимы.
Поэтому я решил написать серию статей, в которых рассматриваются эти, обсуждаемые мной, вопросы. Первая статья будет посвящена изучению того, как скомпилировать программу на C++.

Трехэтапный процесс

Компиляция программы на C++ включает взятие написанного нами исходного кода (файлы .cpp, .c, .h, .hpp) и преобразование их в исполняемый файл или библиотеку, которая может работать на указанной платформе.

Этот процесс можно разделить на три основных этапа:

1. Препроцесинг
2. Компиляция
3. Компоновка

Препроцесинг

В C++ есть директивы препроцессора (идентифицируются в коде префиксом #), определяющие преобразования, которые должны выполняться в исходном коде до его компиляции.

Вы можете узнать больше о директивах препроцессора здесь. Первый этап компиляции программы на C++ с использованием препроцессора предполагает выполнение этих преобразований.

Что именно делает препроцессор, зависит от директивы.

Например, мы часто разбиваем код на отдельные файлы, чтобы упростить организацию и чтение. Чтобы связать код в одном файле с кодом из другого мы используем директиву #include.

При компиляции нашей программы на C++ препроцессор берет этот #include и копирует код, определенный в хедере, в файл, который его включает. Это экономит наше время и исключает возможность возникновения ошибок, которые могли бы возникнуть при ручном копировать кода между файлами.

Директива include является лишь одним примером предопределенных директив, другие примеры вы можете посмотреть в этой статье.

К концу стадии препроцессинга все директивы препроцессора в вашем коде будут обработаны препроцессором компилятора, и результирующий код будет готов к компиляции.

Компиляция

Компиляция является следующим этапом в процессе и связана с превращением исходного кода, который мы пишем, в нечто, понятное компьютеру — машинный код.

Компиляция C++ сама по себе является двухэтапным процессом. Во-первых, компилятор берет исходный код и конвертирует его в язык ассемблера. Ассемблер является языком программирования низкого уровня, который в большей степени похож на машинные инструкции процессора.

Во-вторых, исходный код, преобразованный в язык ассемблера, снова преобразуется в машинный код с использованием ассемблера. В результате получается набор файлов, хранящихся в промежуточном файловом формате, известном как объектный файл.

Примечание: машинный код состоит из команд, написанных в двоичном формате, в терминах машинного языка, потому что именно это тот код, который фактически понимает процессор.

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

На этапе компиляции мы будем предупреждены о любых ошибках в нашем коде, которые приводят к тому, что наш код не компилируется. Все ошибки на этом этапе вызваны тем, что компилятор не понимает написанный нами код.

Код не будет распознаваемым C++, если мы где-то перепутали наш синтаксис. В типичных примерах неудачной компиляции не хватает точки с запятой, неправильно написано ключевое слово C++ или добавлено слишком многих фигурных скобок в конце метода.

Если обнаружена ошибка, компиляция полностью останавливается. Вы не сможете скомпилировать свой C++ код, пока все ошибки не будут исправлены.

Компоновка

Завершающим этапом процесса является компоновка, которая связана с извлечением наших результатов из предыдущего шага и связыванием всего этого вместе для создания фактического исполняемого файла или библиотеки.

Первым шагом на этом этапе является компиляция всех объектных файлов в исполняемый файл или библиотеку. Как только этот шаг будет успешно завершен, следующим шагом будет связывание этого исполняемого файла с любыми внешними библиотеками, которые мы хотим использовать в нашей программе.

Примечание: библиотека — это просто повторно используемая коллекция функций, классов и объектов, которые имеют общее назначение, например, математическая библиотека.

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

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

Предполагая, что на этом этапе ошибок не возникнет, компилятор предоставит нам исполняемый файл или библиотеку.

Сборка

Я думаю, стоит упомянуть еще одну вещь: в IDE, такой как Visual Studio, описанные шаги компиляции сгруппированы в процесс, называемый сборка (build). Типичный рабочий процесс при создании программы — сборка, а затем отладка (debug).

Происходит следующее: сборка создает исполняемый файл (путем компиляции и компоновки кода) или список ошибок в зависимости от того, насколько хорошо мы справились с написанием кода со времени нашей последней сборки. Когда мы нажмем Start Debugging, Visual Studio запустит созданный исполняемый файл.

Компиляция простой программы на C++

Теперь мы знаем основные этапы компиляции C++ программ. Я подумал, что мы могли бы закончить эту статью, рассмотрев простой пример, который поможет закрепить то, что мы только что изучили.

В этом примере я планирую использовать набор инструментов MSCV и собирать его из командной строки разработчика.

Это не руководство по настройке и использованию набора инструментов MSCV из командной строки, поэтому, если вам это интересно, вы можете найти больше информации здесь.

Шаги, которые мы собираемся выполнить:

1. Создадим папку для нашей C++ программы.
2. Перейдем в эту папку.
3. Создадим нашу C++ программу в редакторе (я использовал Visual Studio Code).
4. Скомпилируем наш исходный код в объектные файлы.
5. Скомпонуем наши объектные файлы, чтобы создать исполняемый файл.

Создаем место для хранения нашей C++ программы

Все, что мы делаем на этом шаге, это используем команду Windows md для создания каталога по указанному пути с именем HelloWorld. Мы могли бы просто создать папку из проводника, но это не так круто.

Переходим в папку

Все, что мы делаем на этом шаге, — это перемещаемся в нашу папку с помощью команды cd, за которой следует путь, по которому мы хотим перейти. В нашем случае это папка, которую мы создали на предыдущем шаге.

Мы делаем это, чтобы облегчить себе жизнь.

Если мы не переходим к папке для каждого файла, который мы хотим скомпилировать, нам нужно указать полный путь, но если мы находимся в соответствующей папке, то нам достаточно указать только имя файла.

Пишем код на C++

class HelloWorld
{
public:
void PrintHelloWorld();
};
#include "HelloWorld.h"
#include <iostream>
using namespace std;
void HelloWorld::PrintHelloWorld()
{
std::cout << "Hello World";
}
#include "HelloWorld.h"
int main()
{
HelloWorld hello;
hello.PrintHelloWorld();
return 0;
}

Приведенный выше код представляет собой очень простую программу, содержащую три файла: main.cpp, HelloWorld.h, и HelloWorld.cpp.

Наш заголовочный файл HelloWorld определяет единственную функцию PrintHelloWorld(), реализация этой функции определена в HelloWorld.cpp, а фактическое создание объекта HelloWorld и вызов его функции выполняется из main.cpp.

Примечание. Эти файлы сохраняются в папке, которую мы создали ранее.

Компиляция программы

Чтобы скомпилировать и скомпоновать нашу программу, мы просто используем команду cl, за которой следуют все файлы .cpp, которые мы хотим скомпилировать. Если мы хотим скомпилировать без компоновки, нужно использовать команду cl /c.

Примечание: мы не включаем файл .h в компиляцию, потому что его содержимое автоматически включается в main.cpp и HelloWorld.cpp препроцессором благодаря директиве препроцессора #include.

На изображении выше показаны объектные файлы для наших двух исходных файлов .cpp. Также обратите внимание, что у нас нет исполняемого файла, потому что мы не запускали компоновщик.

Компоновка

На этом финальном этапе нам нужно скомпоновать наши объектные файлы для получения окончательного исполняемого файла.

Для этого мы используем команду LINK, за которой указываем созданные объектные файлы.

Теперь все, что нам нужно сделать, это дважды кликнуть по helloworld.exe, чтобы запустить нашу программу.

Стоит отметить, что, учитывая, что наша программа производит вывод в консоль как раз перед вызовом return из main, консоль может не появиться, или же она будет отображена очень недолго.

Распространенным решением для обеспечения того, чтобы консоль оставалась открытой, является запрос пользовательского ввода в конце программы с использованием cin.

Это очень примитивный пример, но я надеюсь, что он поможет понять, как компилируется программа на C++.

Есть еще много вещей, которые мы не рассмотрели, например, как скомпоновать внешние библиотеки, как наш код может быть скомпилирован на нескольких платформах, и как лучше справляться с компиляцией больших программ на C++.

Существует также гораздо лучший способ компилировать и компоновать программы, нежели вводить каждый файл в командную строку, и нет, это не просто запуск сборки в вашей IDE.

Резюме

Компиляция программы на C++ — это трехэтапный процесс: препроцессинг, компиляция и компоновка.

Препроцессор обрабатывает директивы препроцессора, такие как #include, компиляция преобразует файлы исходного кода в машинный код, хранимый в объектных файлах, а компоновка связывает ссылки на объектные файлы и внешние библиотеки для создания исполняемого файла или файла библиотеки.

Ссылки

• en.wikipedia.org/wiki/C%2B%2B
• stackoverflow.com/questions/6264249/how-does-the-compilation-linking-process-work
• faculty.cs.niu.edu/~mcmahon/CS241/Notes/compile.html
• www.learncpp.com/cpp-tutorial/introduction-to-the-compiler-linker-and-libraries

Пройти тестирование и узнать подробнее о курсе.