Как собрать программу из исходников github
БлогNot. Как собрать проект C++ с github из исходников и подключить его к Visual Studio
Как собрать проект C++ с github из исходников и подключить его к Visual Studio
Благодаря менеджеру пакетов winget, уже входящему в актуальные сборки масдайки, теперь в Windows 10 можно инсталлировать приложения одной простой консольной командой (см. также доку от Микрософта).
Но мы рассмотрим сейчас ситуацию, когда у нас есть только ссылка на исходники проекта, скажем, на Гитхабе (возьмём для примера библиотеку для простых чисел primesieve) и нужно каким-то образом скомпилировать внешний проект в своей Studio, чтобы воспользоваться его возможностями в своём приложении.
В противном случае, конечно же, нестандартный include вроде этого, который вы нашли в коде-образце
работать не будет ни за что.
Первым делом скачаем все исходники внешнего проекта «как есть» в архиве .zip, для этого у нас на гитхабе есть кнопка «Download ZIP»:
Как загрузить проект с github в архиве .zip
Развернём проект, не создавая новой папки, если у вашего архиватора нет такого же пункта меню, просто сотрите предлагаемое архиватором имя новой папки, потому что папка уже есть в архиве:
Извлечь внешний проект из архива, не создавая новой папки
Если покопаться в файле readme.md проекта, как правило, можно найти инструкцию по установке (Build instructions) и даже «Detailed build instructions», где говорится, в числе прочего, и о компиляции проекта под Microsoft Visual C++:
Команды cmake для компиляции проекта со страницы документации
Откроем свой «некомпилируемый» без нужной библиотеки проект в Studio (я использую актуальную сборку версии 2019) и обратимся к команде меню Вид — Терминал. Выберем инструмент «Командная строка разработчика» (по умолчанию в новых сборках теперь выбран PowerShell, впрочем, если в документации приведены команды PowerShell, то применяйте их).
У Микрософта инструмент описан вот здесь.
Командная строка разработчика в Studio
В командной строке пишем команды из документации, но сначала, конечно, нужно перейти в ту папку, где у вас развёрнут скачанный проект. Мне понадобилось ввести в консоли следующее, завершая каждую команду нажатием Enter:
— теперь я в нужной папке, так как развернул свой архив в папку d:\temp
Далее как написано:
Можно просто копировать команды со страницы документации, в окне консоли вверху есть стандартная кнопочка «Вставить». А вот точка в записи команд имеет значение, это ссылка на текущую папку!
Ну и, конечно, для другой версии Studio будет другое указание компилятора, узнать своё можно командой
Нужный генератор будет помечен в списке «звёздочкой».
Теперь проект можно открывать в Studio и работать с ним, все нужные файлы есть в папке d:\temp\primesieve-master
Но мы хотим подключить всё, что нужно, к своему имеющемуся проекту, а не пытаться модифицировать чужую библиотеку.
- Меню Проект — Свойства, слева выбираем Свойства конфигурации, C/C++, Общие, раскрываем поле «Дополнительные каталоги включаемых файлов», говорим «Изменить» и показываем на папку D:\Temp\primesieve-master\include . В вашем проекте, как правило, тоже будет вложенная папка include .
- В том же окне выбираем Компоновщик — Общие — Дополнительные каталоги библиотек, «Изменить» и добавляем путь D:\Temp\primesieve-master\Release . Этого может оказаться мало, у вашего проекта и внешнего должны быть выбраны одинаковые конфигурации решения. Так как я выбрал Release для внешнего проекта, то и в своём проекте в списке «Конфигурации решения» (на стандартной панели инструментов) указал Release и платформу x64. Можно было работать и с Debug, но тогда и внешний проект компилируем как Debug и потом выбираем путь D:\Temp\primesieve-master\Debug .
- В списке C/C++ — Создание кода — Библиотека времени выполнения выбрал Многопоточный DLL (/MD), иначе будет «LNK2038: обнаружено несоответствие для ‘RuntimeLibrary’: значение ‘MT_StaticRelease’ не соответствует значению ‘MD_DynamicRelease’ в file.obj».
- Сам файл библиотеки, как правило имеющий тип .lib , тоже нужно прописать. Всё в том же окне свойства проекта выбираем список Компоновщик — Ввод, раскрываем список «Дополнительные зависимости», жмём «Изменить» и указываем в поле ввода имя файла библиотеки primesieve.lib
- На всякий случай, проверяем, что у нас в списке Компоновщик — Система — Подсистема, у меня там просто Консоль (/SUBSYSTEM:CONSOLE) , для других типов проектов может понадобиться изменение и этой настройки.
После этого у меня всё заработало.
Ну а конкретная задача, на которой я проверял библиотеку — печать самых длинных цепочек последовательных простых чисел, в которых разница между соседними значениями строго возрастает или строго убывает, предел счёта равен 1000000, вот сама программа:
Ответы вышли такие:
За счёт хорошо оптимизированного кода библиотеки считается всё мгновенно.
Начало работы: git, gcc и make
В прошлой статье вы подняли окружение для разработки и компиляции gcc под Windows (или установили виртуальную машину с Ubuntu/Debian), а так же зарегистрировались на GitHub. Сейчас мы напишем простейшую программу на C и научимся простейшему использованию git и make.
Для начала вы должны выбрать текстовый редактор, в котором будете писать код. Под Linux-ом это может быть консольный редактор nano или vim (оба предустановлены в Debian и Ubuntu), графический gedit или sublime_text (предустановлен в Debian).
В окружении Windows для того, чтобы удобно использовать текстовый редактор из консоли bash нужно немного исправить его конфигурацию. Для этого открываем вашим любимым текстовым редактором файл C:\MinGW\msys\1.0\etc\profile и в самый конец файла на новой строчке добавляем следующее:
Например, для Notepad++ со стандартным путем установки это выглядит так:
Команда alias задает псевдоним какой-то команды в bash. В данном случае, вы дали знать оболочке, что хотите, чтобы при обращении к команде “editor” у вас вызывалась программа, расположеная по пути “C:\Program Files (x86)\Notepad++\notepad++.exe”.
Скорее всего, это было последнее отличие для Windows, и в следующих статьях материал будет актуален для обеих систем.
Написание первого кода
Откроем консоль bash и создадим новую директорию с именем test1 в нашей домашней директории. Для этого введем команду:
Теперь войдем в нее. Аналогично,
Заголовок окна и строка приглашения (та, что на строку выше “$” в Windows, в той же строке перед символов “$” в Linux) должна измениться и отображать текущий путь. Нетрудно заметить, что он начинается с символа“
”. В Unix-системах этот символ означает домашнюю директорию.
Теперь же приступим непосредственно к редактированию кода.
В консоли bash выполним следующую команду (если вы используете Sublime Text 3 под Linux, то вместо editor используйте sublime_text):
Тем самым мы откроем текстовый редактор для файла main.c в текущей директории. Эта команда удобна тем, что сработает и в Windows, и в Linux с любым текстовым редактором (кроме Sublime Text, если это не было настроено вручную). Если такого файла не существовало ранее, то этот файл будет создан.
Введем в него следующий код:
И сохраним файл. Теперь этот исходный код необходимо скомпилировать. Введем команду:
В результате у нас получится файл main (или main.exe под Windows). Но давайте сначала разберем саму команду.
И так, команда состоит из 2 частей: собственно команды и ее параметров. В качестве команды здесь у нас выступает имя компилятора — gcc, а вот параметры рассмотрим подробнее.
Параметр -o задает имя выходного файла скомпилированой программы. Если его не указывать, то выходной файл компилятора будет называться a.out (таким образом, этот параметр необязательный).
Далее следуют необязательные параметры -Wall и -Werror. Легко заметить, что оба начинаются с “-W”, что означает, что они относятся к обработке предупреждений (Warning-и). “-Wall” включает вывод всех сообщений warningов, а “-Werror” заставляет компилятор обрабатывать их как ошибки, то есть прерывать компиляцию, когда такой warning встречается.
Далее следует последний и обязательный параметр — имя компилируемого файла. Тут все просто. Этот параметр нельзя опускать (иначе компилятор не узнает, что надо компилировать).
Можем проверить работу нашей программы, введя в консоли:
Если на экране вывелась строка “Hello, world!”, то вы все сделали правильно.
Начало работы с Git
Git — это такая система контроля версий. Это значит, что она используется для хранения всей истории изменения проекта, быстрого перехода между версиями проекта, а так же для удобства командной разработки. Основной объект оперирования (то, с чем вы будете работать) — это репозиторий. Для человека он выглядит как обычная директория с файлами, в которой также есть и скрытая папка .git, в которой хранится история изменений и другая служебная информация.
Начнем работу. Для того, чтобы создать пустой репозиторий в текущей папке, введем команду:
(для создания новой пустой папки и репозитория в нем нужно ввести имя папки после “init”). В данный момент все изменения (а на данный момент для git-а файл main.c, который мы создали ранее, это “изменение”) еще не добавлены в репозиторий (т.н. “unstaged changes”). Мы можем просмотреть текущее состояние репозитория (т.е. все неизмененные, измененные и недобавленные файлы) с помощью команды
Видим, что файлы, которые создали мы и компилятор находятся в списке “Untracked files”. Это означает, что они еще не добавлены в репозиторий или не добавлены в текущий коммит.
Коммитом называется операция фиксации всех изменений, сделанных в репозитории и добавленых к коммиту. Также к коммиту обычно прилагается комментарий, описывающий что именно изменилось во время данной фиксации. На практике очень важно писать осмысленные и правильные комментарии к коммиту.
Давайте добавим наш файл к коммиту и зафиксируем изменения.
После этого должен создасться первый коммит, а в выводе команды “git status” файл main.c должен исчезнуть из списка “Untracked files”. С помощью команды “git log” можно просмотреть список коммитов.
Обратите внимание, мы не просто так добавили в репозиторий только файл с исходным кодом. За редким исключением в репозиторий добавляются только plaintext-файлы, т.е. файлы, которые содержат человекочитаемый текст. Binary-файлы в репозиторий добавлять не нужно (в git существует даже специальный файл, в который можно записать список или маску всех бинарных файлов проекта, чтобы случайно не добавить их).
Давайте теперь внесем изменения в наш код.
Для начала об изменениях в коде. Выше, при компиляции, вы уже познакомились с понятием параметра командной строки. Функция main принимает 2 параметра — argc и argv. Так вот, argc — это количество параметров, а argv — это массив, содержащий в элементах каждый из параметров. Теперь наша программа проверяет, больше ли 1 количество параметров (потому что сама команда на всех системах тоже считается за параметр и хранится в argv[0] — это важно!) и если это так, то выводит сообщение “Hello, <тут первый параметр>!”, в противном случае выводит “Hello, <имя программы, оно же нулевой параметр>!”.
Скомпилируем программу заново (используя ту же команду, что и в прошлый раз) и проверим результат ее выполнения, введя:
Вместо самой команды вывелся полный путь к вызываемому файлу, потому что оболочка командной строки автоматически раскрывает команду в полный путь к файлу.
Теперь нужно добавить измененный файл к текущему коммиту. Делается это той же командой “git add” (как и добавление нового файла).
И так, теперь в списке коммитов отображается 2 коммита. Для самого git коммиты — это специальные файлы в формате patch, которые позволяют на уровне строк (т.е. даже если в строке будет отличаться всего один символ, будет полностью удалена старая строка и добавлена измененная) находить разницу между файлами. Чтобы посмотреть, как выглядит коммит, использутся команда “git show”.
Теперь рассмотрим, как отправлять код на удаленный репозиторий (например GitHub). Переходим по этой ссылке и создаем репозиторий с названием “test1". Настройки должны выглядеть как на скриншоте ниже.
Создаем репозиторий. После этого GitHub выдает нам страницу с некоторым набором действий, которые именуются “Quick setup”. На странице будет переключатель “HTTPS | SSH”, по умолчанию установленый в HTTPS. Если вы создавали ssh-ключ с помощью ssh-keygen, то можете выбрать SSH (как я писал ранее, тогда вам не придется вводить пароль при отправке изменений). В противном случае ничего не трогайте.
Из всех команд, которые предлагает нам GitHub, нас интересует только та, которая начинается с “git remote add”. Копируем ее и выполняем в консоли. Эта команда добавляет удаленный адрес репозитория, в который git сможет отправлять все сделаные вами изменения.
(это пример команды). Здесь “origin” — это имя источника (удаленного репозитория). “origin” — это имя для основного источника (их может быть несколько). После этого введем:
Как видим, в этой команде указывается имя источника, а так же название ветки “master”. Дело в том, что у репозитория git может быть несколько ответвлений, которые после могут сливаться в главное. Но это мы пока рассматривать не будем.
Если вы выбрали HTTPS-режим, то у вас запросится логин и пароль. После этого изменения отправятся на сервер и мы сможем их увидеть на странице репозитория GitHub.
Написание сценариев make
GNU make — это система сборки проектов. Сейчас наш проект состоит из одного файла и собирали мы его одной командой, однако на практике файлов могут быть сотни и тысячи, и для того, чтобы не компилировать каждый файл вручную и нужна система сборки.
make имеет очень простой синтаксис. У make есть так называемые “цели”, т.е. задачи, которые система сборки будет выполнять. Цели задаются таким образом: “<имя_цели>:”. Имя цели — строчные английские символы и цифры. Команды внутри цели — это обычные консольные команды bash. Они должны быть отделены от начала строки одним символом табуляции (нажатие кнопки Tab, таким образом make понимаем, что это именно команда, а не цель). Сам файл с целями и командами make должен называться “Makefile” (обязательно с большой буквы). Цель по умолчанию называется “all”.
Рассмотрим пример простейшего Makefile:
(если будете копировать здесь и далее, то отступы сделаны с помощью пробелов, но надо их сделать с помощью клавиши Tab).
Здесь задана только одна цель — “all” и одна команда, которой мы и раньше компилировали наш исходник. Добавим еще две цели, одну для очистки директории от мусора (за мусор примем скомпилированый файл) и тестирования нашего проекта.
Мы добавили две цели: в цели test — команды для тестирования, которые мы использовали ранее, а в цели clean — команда для удаления скомпилированного файла “main” (“main.exe” для Windows).
Протестируем полученный файл:
После этого у вас должен скомпилироваться код main.c, вывестись 2 результата запуска (с параметром и без), а потом удалиться исполняемый файл (“make clean” завершится с ошибкой, т.к. одного из файлов в зависимости от ОС у вас не будет)
Как видно, в файле часто используется название “main”. Для того, чтобы вынести его, в make есть поддержка переменных. Переменные задаются вне целей: “<имя переменной>:=<значение>”, каждая на новой строке. В командах значение переменной можно использовать с помощью конструкции “$(<имя переменной>)”. Добавим переменную target в наш Makefile:
Протестируйте этот файл еще раз.
Самостоятельное задание: добавьте Makefile в репозиторий и отправьте изменения на GitHub.
How do I compile a GitHub project? [closed]
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago .
I’ve tried for few hours.. and failed. i can’t seem to get it to work. ( in NetBeans)
I’ve added libraries that creator pointed out, source and nbproject — I get errors.
Can someone tell me what to do step by step? Thank you in advance.
( i’ve tried adding it — I downloaded the zip from github then I created new project in netbeams (selected as just Java) then I went to «files» tab and dragged and dropped down src folder from zip i downloaded from GitHub then nbproject and the rest. I’ve got an JAVADOC error. )
Как установить программное обеспечение с помощью Git в Linux
Вам сказали «клонировать репо и построить его», и вы не знаете, что делать дальше? Мы покажем вам, как запустить эту программу на GitHub в Linux, даже если вы новичок.
Инструкции, составляющие компьютерную программу, пишутся, редактируются и сохраняются в текстовых файлах. Затем эти файлы обрабатывает программа, называемая компилятором. Этот создает исполняемую версию программы. Текстовые файлы инструкций называются исходным кодом. Версия программы, которая действительно может работать на компьютере, называется двоичной или исполняемой.
Это упрощенная версия событий, но она рисует правильную — если обобщить — картину. На практике вы найдете множество вариантов этой модели. Иногда другие программы создают текстовые файлы. В других случаях исходный код запускается внутри переводчика и не требует компиляции, и так далее.
Однако одна универсальная истина для всех программных проектов заключается в следующем: файлы исходного кода драгоценности короны, и за ними нужно так же тщательно ухаживать.
Программы контроля версий
Все файлы исходного кода в проекте называются базой кода. В крупных проектах над кодовой базой часто работает много разработчиков. Каждое изменение кода необходимо отслеживать и идентифицировать. При необходимости изменения должны быть обратимыми. Если разные разработчики вносят изменения в один и тот же файл исходного кода, их правки необходимо объединить.
Поэтому неудивительно, что существуют программы, называемые системами контроля версий, чтобы упростить управление изменениями в кодовой базе. Системы контроля версий содержат все предыдущие версии каждого файла в базе кода, и каждое изменение записывается, комментируется и отслеживается.
Маленькая штука под названием Git
Линус Торвальдс, создатель ядра Linux, разработал программу контроля версий под названием Git для администрирования кодовой базы ядра Linux. В настоящее время это наиболее широко используемое программное обеспечение для контроля версий. Миллионы людей используют его буквально.
В Git кодовая база проекта хранится в репозиториях. В дополнение к локальным репозиториям, которые находятся на компьютерах разработчика и, возможно, на центральном сервере в сети, рекомендуется иметь внешний или удаленный репозиторий.
И здесь на помощь приходит GitHub.
GitHub
GitHub был создан в результате успеха git. Основатели увидели растущую потребность в безопасных удаленных репозиториях git. Они начали бизнес предоставление облачной платформы чтобы группы разработчиков могли размещать удаленные репозитории. По состоянию на апрель 2019 года на GitHub размещено более 100 миллионов репозиториев.
Если приложение является проектом с открытым исходным кодом, очень высоки шансы, что оно будет размещено на GitHub. Доступны и другие платформы репозиториев, такие как BitBucket и GitLab, но на GitHub приходится львиная доля репозиториев с открытым исходным кодом.
Анатомия репозитория
Репозиторий GitHub состоит из папок, содержащих файлы, такие как важнейшие файлы исходного кода. Обычно в репозитории есть много других типов файлов. Это могут быть файлы документации, страницы руководства, файлы лицензий на программное обеспечение, инструкции по сборке и файлы сценариев оболочки. Нет никаких правил относительно того, что репозиторий должен или должен содержать, но есть соглашения.
Если вы разбираетесь в одной кухне, вы можете ориентироваться на любой кухне. То же самое и с репозиториями. Как только вы поймете условные обозначения, вы поймете, где найти то, что вам нужно.
Итак, как получить копию репозитория на свой компьютер и как встроить программу в двоичный исполняемый файл?
Файл readme
Традиционно включать файл readme в репозиторий. Его можно назвать readme, Readme или README. Он может иметь расширение «.md» или вообще не иметь расширения.
Посмотрим на GitHub репозиторий для редактора Atom. Вы видите длинный список папок и файлов. Прокрутите вниз, и вы увидите содержимое файла README.md.
GitHub автоматически помещает содержимое файла readme на главную страницу репозитория. Если файл readme имеет расширение «.md», он будет содержать Разметка Markdown язык. Это позволяет разработчикам использовать элементы стиля, такие как шрифты, маркеры и изображения.
Как правило, в файле readme есть разделы, в которых рассказывается, о чем идет речь, о типе лицензии, о том, кто поддерживает проект, как принять участие и как создать и запустить приложение.
Если в нем нет фактических инструкций по сборке, он сообщит вам, где найти эту информацию. Другая информация, полезная для создания приложения, такая как необходимые инструменты сборки и другие зависимости, может быть указана здесь, или ссылка может привести вас к этой информации.
Репозиторий коробок
Наша миссия — клонировать репозиторий ящиков, а затем создайте приложение ящиков.
Репозиторий имеет ту же структуру, что и Atom. Там список папок и файлов, а ниже — содержимое файла readme. Он следует стандартной схеме репозитория, но это меньший по размеру проект, поэтому в нем меньше папок и файлов.
Файл readme тоже короче. В нем есть раздел под названием «Разработка». В этом разделе есть ссылка под названием «Построение из исходного кода». Если мы перейдем по этой ссылке, мы должны найти информацию нам нужно.
Обычно для навигации по репозиторию и поиска нужной информации требуется легкое отслеживание, но это не сложно. Внимательно прочтите все на странице репозитория. Иногда информация присутствует, но может не отображаться на видном месте.
Зависимости
На странице «Сборка из исходного кода» есть раздел «Сборка в Linux», и это как раз то, что нам нужно. Он говорит, что мы должны иметь Компилятор C, Бизон, и Flex установлены.
В инструкциях по сборке сказано, что нужно выполнить команду make, поэтому нам также понадобится make.
Инструменты, необходимые для создания этого приложения, — это компилятор C, Bison, Flex, make и Git (для клонирования репозитория на ваш компьютер).
Эта статья была исследована на компьютерах, работающих под управлением дистрибутивов Ubuntu, Fedora и Manjaro Linux. Ни в одном из дистрибутивов не были установлены все эти инструменты — на каждый из них нужно было что-то установить.
Установка набора инструментов
В Ubuntu должны были быть установлены Git, Flex, Bison и make. Вот команды:
В Fedora должны были быть установлены Flex, Bison и make. Вот команды:
На Manjaro должны были быть установлены компилятор GCC, Flex и Bison. Вот команды:
Клонирование репозитория
Каждый репозиторий GitHub имеет определенный веб-адрес, используемый Git для клонирования репозитория на ваш компьютер. На главной странице репозитория ящиков есть зеленая кнопка с надписью «Клонировать или скачать».
Нажмите кнопку, чтобы увидеть веб-адрес. Это адрес, который мы должны передать команде git при клонировании репозитория.
Перейдите в каталог, в который мы хотим клонировать репозиторий, и затем используйте эту команду. Если ваше окно терминала поддерживает это, вы можете скопировать и вставить веб-адрес в команду. Нажмите Ctrl + Shift + V, чтобы вставить в окно терминала GNOME.
Git клонирует удаленный репозиторий и создает на вашем компьютере локальный. Он сообщает нам, что клонируется в каталог под названием «ящики».
Каталог боксов создается в каталоге, из которого вы запустили команду git. Если мы переключимся в каталог box и посмотрим на его содержимое, мы увидим тот же список файлов и папок, который мы видели на странице GitHub.
Большой! Мы успешно клонировали исходный код и другие файлы на наш компьютер. Теперь нам нужно создать приложение.
Сборка приложения
Чтобы собрать приложение, мы должны следовать инструкциям в репозитории GitHub. Иногда мы запускаем определенный файл оболочки, а другие — make. Инструкции по сборке, которым мы следуем, говорят нам запустить make.
Утилита make читает и выполняет набор инструкций из make-файла. Эти инструкции говорят make, как скомпилировать программу и связать ее вместе. make передает инструкции компилятору и другим инструментам сборки.
Команда, которую нам предлагают использовать, вызовет make дважды. Первый вызов make создает приложение, а второй запускает набор тестов.
Команда, которую нам сказали использовать инструкции по сборке:
Многие строки вывода быстро прокручиваются в окне терминала. Примерно через минуту вы вернетесь в командную строку.
Развертывание приложения боксов
Приложение создано, и у нас есть исполняемый двоичный файл. Теперь мы должны скопировать двоичный файл в каталог / usr / bin /. Это позволяет оболочке находить его, когда мы пытаемся его использовать.
Для некоторых приложений это может быть все, что вам нужно сделать. В других случаях вам может потребоваться скопировать дополнительные файлы, такие как страницы руководства и файлы конфигурации, в места в файловой системе. Последнее — то, что мы должны сделать с нашим новым приложением, потому что это было в инструкциях по сборке.
Используйте sudo для запуска этих команд. Первая команда копирует справочную страницу в каталог man1:
Затем скопируйте глобальный файл конфигурации в каталог в / usr / share /:
Наконец, скопируйте двоичный файл в / usr / bin:
Тестирование приложений коробок
Посмотрим, все ли работает! Попытайтесь открыть страницу руководства для команды боксов.
Это воодушевляет! Вы видите страницу руководства, в которой рассказывается, как использовать команду боксов.
Нажмите «Q», чтобы выйти из системы man, и попробуйте использовать команду box.
И получаем ответ:
Это может показаться немного разочаровывающим, учитывая все усилия, которые вы приложили, но суть этого упражнения заключалась в том, чтобы помочь вам вытащить репозиторий из GitHub и построить приложение.
Команда боксов позволяет вам заключать текст, который передается в него, в самые разные фреймы. Некоторые из них можно использовать в качестве комментариев в файлах исходного кода. Приведенный выше формат будет работать, например, как комментарий в файле исходного кода C. Остальные чисто декоративные. Параметр -d (дизайн) позволяет выбрать стиль рамки.
Есть длинный список дизайнов, из которых вы можете выбирать. Чтобы увидеть их все, используйте эту команду:
Сборка завершена
Шаги по сборке из исходного кода обычно просты:
Ознакомьтесь с инструкциями по сборке в репозитории.
Убедитесь, что у вас установлены необходимые инструменты, и установите все, что отсутствует.
Клонируйте репозиторий на свой компьютер.
Следуйте инструкциям по сборке, которые зачастую так же просты, как ввод make.
Скопируйте файл (ы) в нужные места.
Если в инструкциях по сборке есть непонятные шаги, посмотрите, есть ли у проекта форум или сообщество, в которое вы можете отправить вопрос. Если у приложения есть веб-сайт, у них может быть страница «Свяжитесь с нами». Электронная почта разработчика, поддерживающего проект боксов, находится на странице «О программе» сайт коробки. Это щедрый жест с его стороны, типичный для более широкого сообщества разработчиков ПО.