Как собрать приложение из исходников с github
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.
Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.
Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.
После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.
В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.
Создание локального репозитория
Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.
Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.
Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc
Переходим в папку с проектом /home/user/project:
И показываем список файлов с расширением .pyc:
Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:
Очень рекомендуется не спешить и сразу ключ этот не добавлять. Первый раз вызвать команду для просмотра файлов и только убедившись, что в список не попало ничего полезного добавить ключ удаления.
Создадим локальный репозиторий в папке с проектом:
После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.
Добавление файлов в локальный репозиторий
Для добавления файлов используется команда:
После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:
Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:
Что легко увидеть с помощью команды:
Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.
Для того, чтобы добавить все файлы из текущей директории введите:
Если нужно добавить файлы из текущей директории и из всех поддиректориев, то используйте:
Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).
Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.
После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).
Для просмотра текущего состояния можно воспользоваться командой:
После выполнения команды мы увидим, что в stage area находится наш файл:
Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.
Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.
Можно отменить добавления файла readme в staging area с помощью команды:
После выполнения команды, файл readme отметится, как неизмененный системой.
Создание версии проекта
После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:
Каждая новая версия сопровождается комментарием.
После коммита, мы сможем найти два новых объекта внутри .git репозитория.
Посмотрим, что внутри:
Ключ -t показывает тип объекта. В результате мы видим:
Для второго объекта:
Для самого первого файла:
Если мы будем дальше изучать содержимое этих файлов, то обнаружим древовидную структуру. От каждого коммита можно по ссылкам пройти по всем измененным файлам. Для практического применения это не очень нужно, но возможно так будет легче понять, что происходит при работе с системой Git.
Ключ --no-edit нужен, чтобы не вводить заново комментарий.
Можно просмотреть изменения, которые вы внесли последним коммитом:
Ключ --name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.
Если вы продолжили работать и изменили только те файлы, которые были уже добавлены в систему командой git add, вы можете сделать коммит одной командой:
Для просмотра списка всех коммитов, воспользуйтесь командой:
Ключ --oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:
Для того, чтобы просмотреть изменения по конкретному коммиту, достаточно в команду git show добавить хеш значение коммита, которое можно получить с помощью предыдущей команды.
Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:
Для того чтобы удалить все файлы в папке, которые не относятся к проекту и не сохранены в репозитории, можно воспользоваться командой:
Создание репозитория на Github
После регистрации нажимаем кнопочку "+" и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.
В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.
Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).
Можем просмотреть результат добавления с помощью команды:
Если все было правильно сделано, то увидим:
Для того, чтобы отменить регистрацию удаленного репозитария введите:
Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.
Ключ -u используется для того, чтобы установить связь между удаленным репозиторием github и вашей веткой master. Все дальнейшие изменения вы можете переносить на удаленный репозиторий упрощенной командой.
Перенос репозитория на другой компьютер
После того, как репозиторий был создан на Github, его можно скопировать на любой другой компьютер. Для этого применяется команда:
Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).
Так же можно добавить название папки, в которой вы хотите разместить локальный репозиторий.
Работа с одним репозиторием с разных компьютеров
С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.
Для получения обновлений с удаленного репозитория воспользуйтесь командой:
Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:
Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.
Как мы уже знаем, для того чтобы изменения выложить на удаленный репозиторий используется команда:
В случае, если в удаленном репозитории лежат файлы с версией более новой, чем у вас в локальном, то команда git push выдаст ошибку. Если вы уверены, что хотите перезаписать файлы в удаленном репозитории несмотря на конфликт версий, то воспользуйтесь командой:
Иногда возникает необходимость отложить ваши текущие изменения и поработать над файлами, которые находятся в удаленном репозитории. Для этого отложите текущие изменения командой:
После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:
Пользователям Linux необходимо хотя бы приблизительно знать как происходит сборка программ из исходников. Так как вы можете столкнуться стем, что вашей программы может и не быть скомпилированной под ваш дистрибутив. Сама сборка программ не сложна, и обычно описана в файле README или INSTALL, который идет вместе с пакетами для сборки. Так что, будьте внимательны. И так, сборку из исходников мы будем разбирать на примере программы GParted. Но, для начала давайте установим необходимые утилиты – интерпретатор и компилятор, для того, что бы можно было собирать программы. Для установки необходимых утилит вводим команду:
Debian/Ubuntu
sudo apt install build-essential automake autoconf
Arch/Manjaro
sudo pacman -S base-devel --needed
Сборка программ c Github
И начнем мы с GParted, сборку или как еще называется данный процесс – компиляцию мы будем выполнять в Ubuntu 20.04 . Вы можете спросить почему именно в Ubuntu, отвечу, для Arch Linux и подобных есть AUR. Да и со сборкой программ в Arch мы разберемся чуть позже. Там можно найти практически все программы, которые существуют для Linux. Для начала нужно скачать исходники программы, для этого переходим на сайт, скачиваем, а затем распаковываем архив. Так же можно выполнить команду:
Затем переходим в папку:
Теперь заглянем в файл README и посмотрим его внимательно. Если приглядеться, то можно увидеть какие зависимости необходимы доустановить:
Обратите внимания, что GPArted хорошо документированная, и для установки под каждый дистрибутив имеется инструкция с дополнительными зависимостями. Устанавливаем зависимости и выполняем команду для того, что бы у вас сформировался установочный файл:
Если проблема с зависимостями у вас останется, то вы увидите об этом вывод:
После того, как вы установите все необходимые зависимости, запускаете снова “autogen.sh”. В итоге он вам скажет что можно приступать к дальнейшим действиям:
Далее запускаем “make” и затем когда “make” выполнит свою работу, запускаем “sudo make install”. Обратите внимания, в некоторых инструкциях не упоминается о том, что нужно установку программы выполнять именно от “sudo”, а именно: “sudo make install”. Из за этого у вас могут возникнуть проблемы. И так продолжаем сборку программы вводим команды:
make
sudo make install
Стоит отметить, что многие программы с открытым исходным кодом, можно найти на github. Там обычно самая последняя версия программы, по этому, если есть такая возможность, то лучше собирать программы с github.
После установки можно найти программу в меню установленных программ.
Сборка программ из архива
Распаковывать архив можно из терминала, а можно при помощи графического интерфейса, например программой Ark или Менеджер архивов. Тут все зависит от того, как вам удобней. Для того что бы распаковать архив в терминале, нужно выполнить определенную команду. На примере с GParted такой командой будет:
tar xzf gparted-1.1.0.tar.gz
Примечание, tar является утилитой командной строки для распаковки архивов. И так, затем переходим в папку с распакованной программой и смотрим какие там имеются файлы. Тут как раз имеются README:
Для наглядности я открою файл README в графической утилите Mousepad. Как вы можете заметить, в инструкции подробно прописано как устанавливать данную программу из исходников:
Для того что бы собрать данную программу, достаточно выполнить команды, которые прописаны в инструкции. Так как мы уже распаковали данный архив, пропускаем это шаг. Если вы не знаете как перейти в терминале в директорию программы, поясню. А если знаете, то пропустите данный шаг. Для того что бы перейти в терминале в нужную директорию, используется команда “ cd “. Например, у вас папка с программой находится по адресу “Загрузки – папка с программой”, выполняем команду:
После чего можно посмотреть что у нас имеется в данной директории введя команду “ ls “, после чего снова вводим команду “ cd ” и переходим в нужную нам директорию. Например:
Теперь приступаем к сборке программы GParted. Для этого вводим команды которые написаны в файле README.
На этом этапе установки могут возникнуть проблемы с зависимостями. По этому их необходимо установить:
После того как все необходимые зависимости были установлены, снова запускаем “./configure” и продолжаем компиляцию программы как описано выше. А именно, после запуска “./configure” запускаем “make”, а затем “sudo make install”.
Ошибки при сборке программы
Возможно, при компилировании у вас могут возникнуть проблемы с зависимостями. Для этого надо будет устанавливать необходимые пакеты. Обычно если у вас не хватает зависимостей, вы увидите во время выполнения команды ./configure ошибки. Если же вы не знаете какой зависимости не хватает, то тут выручит поисковик.
После того как вы установите необходимые зависимости, снова необходимо запустить ./configure. А может быть и так, что у вас не будет файла ./configure, попробуйте запустить другие скрипты:
Если таких скриптов вы не смогли найти, то можно выполнить последовательно следующие команды:
aclocal
autoheader
automake --gnu --add-missing --copy --foreign
autoconf -f -Wall
В случае с дистрибутивами Arch/Manjaro необходимые пакеты вы можете подгрузить используя “Менеджер программ”, Предварительно не забыв подключить репозиторий AUR:
Пример необходимых зависимостей при установки в Manjaro программы Blender. Компиляция производилась с использованием файла PKGBUILD:
Удаление программ
Если же вы захотите в будущем удалить GParted, или какую то иную программу, оставьте папку которую скачивали. Так как только в ней есть инструкция куда устанавливались те или иные пакеты. Обычно, в файле README написано как удалять установленные программы. В случае с GParted достаточно перейти в каталог с исходниками и выполнить команду:
Сборка в Arch/Manjaro (Arch Build System – ABS)
В дистрибутивах Arch и Arch подобных есть несколько способов устанавливать программное обеспечение, собственно, как и во многих других дистрибутивах. Но, в Arch имеется AUR, это пользовательский репозиторий, где лежат программы, которые не вошли в официальные репозитории. А так же существует способ собрать программу из исходников и вот тут вы можете столкнуться с тем, что вам попадется файл “PKGBUILD”. PKGBUILD это грубо говоря скрипт, который содержит инструкцию по скачиванию необходимых пакетов. Так же вместе с PKGBUILD могут быть и другие файлы, например “blender.desktop”. Вы можете открыть PKGBUILD и изменить необходимые параметры, но, это только при условии что вы знаете что делаете. Предположительно, вы уже перешли в каталог с исходниками программы, если же нет, сделать это можно командой в терминале “cd и путь к директории”. Для сборки пакета выполняем команду:
Опишу опции которые тут применяются, опция -s произвести проверку и установку зависимостей, а опция i установку самого пакета:
Чтобы установить значение опции, отличное от "по умолчанию", необходимо дописать -DНАЗВАНИЕ_ОПЦИИ=Значение к команде конфигурирования. Команда после этого может выглядеть, например, так:
Чтобы сделать такое действие в CLion, необходимо перейти в: Settings -> CMake -> CMake options.
Если используется Hunter (пакетный менеджер), то прописываются его настройки
На этапе конфигурирования, CMake ожидает файл tools/gate/cmake/HunterGate.cmake .
Если этот файл не существует, возможны 2 варианта:
- Либо (если используется шаблонный репозиторий) необходимо обновить подмодули:
git submodule update --init --recursive
Дополнительные опции для компилятора (могут отсутствовать)
Подключение зависимых библиотек
Затем осуществляется подключение библиотек, в которых нуждается проект (Boost, GTest, Threads и т.д.)
Указания для Hunter о необходимо коллекционирования указанных пакетов
Указания о том, какие пакеты будут использованы (ожидается их наличие)
CONFIG - ключевое слово, показывающее маску названий конфигурационных файлов.
REQUIRED - обязательность подключения пакета (иначе - ошибка).
Добавление целей сборки
После настройки окружающией среды пишется информация о том, что ожидается получить в результате сборки
Указание директорий с заголовочными файлами
Указание библиотек для линковки
Названия библиотек из Hunter, как правило, имеют вид LibraryName::ComponentName .
Данные о библиотеках из пакета, добавленного через find_package хранятся в переменных. Например, для Threads: $
Для сборки тестирования необходимо наличие:
- Добавления пакета googletest (GTest в Hunter)
- Цели для сборки исполняемого файла
- Линковки gtest_main и gtest (GTest::main и GTest::gtest в Hunter) к цели
- Включенного тестирования в конфигурационном файле
Можно добавлять несколько тестовых целей под разными названиями. И даже с использованием разных фреймворков.
Для сборки и выполнения тестирования необходимо выполнить следующую команду (ожидается предварительное конфигурирование):
Пример тела конфигурационного файла с тестированием:
Для удобства в CLion необходимо добавить конфигурацию сборки google test.
Начало конфигурации. Как правило, его трогать не надо.
Далее прописываются цели, которые будут проанализированы на процент покрытия.
Конец конфигурации. Как правило, не надо трогать.
Для начала необходимо настроить окружение. Как правило, это не надо трогать
Далее необходимо указать jobs'ы, которые будет выполнять Travis. Jobs содержит название и команды.
К таким относятся, например, правила для веток и для уведомлений. Например:
Я загрузил мертвую простую программу для Windows из GitHub ( это , если это уместно). Я загрузил его в виде файла ZIP, но не могу понять, как его установить. Это написано на C, я думаю. Нужен ли мне компилятор? (Visual Studio?) Есть что-то простое, что мне не хватает?
Извините, это, очевидно, серьезная проблема с нубами. Как? Там нет исполняемого файла. Вам, вероятно, понадобится Windows SDK и связанные заголовки C для компиляции программы. Обычно упоминаются зависимости, а инструкции по компиляции включаются в файл Readme. В этом случае ни один из них не включен, поэтому вы должны попросить владельца репо / автора проекта получить соответствующую информацию. Вам нужен компилятор. Я хотел бы обратиться к разработчику и спросить, как его построить. Обычно, например, программное обеспечение для Linux, поставляемое в качестве источника, содержит инструкции по сборке, но я не вижу его на Github. Вы не загрузили реальную программу, вы загрузили исходный код программы и, да, вам нужно сначала скомпилировать ее. Судя по make-файлу, вам нужно собрать все, что есть в MINGW.Github в основном используется программистами для совместной работы над проектами. Параметр «Загрузить ZIP» загружает копию исходного кода на ваш компьютер. Это , как правило , 1 не содержит копии скомпилированных используемых исполняемых файлов / двоичных файлов (например, EXE - файлы)
Releases - это функция Github для доставки программного обеспечения конечным пользователям (которые обычно не заинтересованы в реальном кодировании). Релизы сопровождаются примечаниями к выпуску и ссылками для загрузки программного обеспечения или исходного кода. Это первое место, где вы должны проверить двоичные файлы .
В вашем случае на странице релизов предлагаются файлы для загрузки и настройки.
Однако многие проекты не будут иметь никаких выпусков (особенно не для Windows), и в этом случае вы можете выполнить одно из следующих действий:
Поиск двоичных файлов в других местах в Интернете. Обычно поисковые системы, такие как DuckDuckGo (или Google , если вы предпочитаете), легко найдут то, что вы хотите. Попробуйте найти <application name> for Windows или <application name> exe .
Скомпилируйте это самостоятельно. Вы должны иметь хотя бы некоторые базовые знания языка программирования, чтобы иметь возможность сделать это. Здесь снова, поисковые системы могут быть чрезвычайно полезными. Попробуйте найти compile <application name> on Windows или MinGW compile <application name> .
Здесь я рассмотрю основы компиляции утилит для Widnows:
Выполните следующие команды в cmd или powershell :
1 Примечание. Иногда bin среди загруженных файлов может быть папка , которая должна содержать исполняемые файлы / исполняемые файлы
Также смотрите Cygwin и GOW, если вы хотите использовать утилиты командной строки GNU / Linux в Windows. Я делаю несколько последних версий некоторых полезных исполняемых файлов, доступных для скачивания здесь .
Спасибо, это отличный ответ, и я изменил его, чтобы пометить как окончательный. (Ранее я редактировал свой вопрос, чтобы было яснее, что это то, что я искал, но по какой-то причине BoundaryImposition отредактировал его.) Я не думаю, что это удовлетворяет просьбу Айбоба о вознаграждении, но это между вами и ней / ним. @JoshFriedlander Рад быть полезным! Я добавлю больше к ответу позже . Да, я болтал с JourneymanGeek (Aibobot), он собирается ждать несколько дней, пока новые ответы не появятся. Этот проект может не иметь никаких, но обратите внимание, что большинство проектов, вероятно, будут иметь зависимости , а это значит, что если вы идете по пути компиляции, вам может понадобиться отследить библиотеки, от которых зависит программное обеспечение, загрузить их и установить их ( или скомпилировать их тоже). Обычно это не так просто, как просто запустить make-файл; некоторые из них могут даже иметь другие сценарии сборки, такие как cmake, скрипт настройки и т. д. Действительно ли процесс настолько прост в большинстве случаев? Какая часть утилит github требует существенно больших знаний для их компиляции, чем то, что Вы описали здесь?Вы оглядываетесь вокруг и находите установщик на странице релиза . Конечно, вы можете скомпилировать исходный код, но я не думаю, что вы этого хотите.
Согласовано. Если вам нужно спросить, вы не хотите компилировать из исходного кода. Если вам нужно спросить, вы, вероятно, не должны устанавливать программное обеспечение, которое доступно только в исходной форме . Я склонен согласиться с @jpaugh. Хотя сборку из исходного кода очень возможно, а иногда и необходимо, это не то, что вы можете просто пойти и спросить «как построить программу на C» в общем виде. Просто слишком много различий. Некоторые удачные программы так же просто, как «скомпилировать эти файлы». Другим нужны make-файлы. Некоторым нужны зависимости, которые будут загружены первыми. Процесс настройки для сборки может быть сложным и не обязательно дружественным к программисту. Прежде всего, однако, вы хотите найти файл в проекте, который объясняет, как построить, потому что особенности зависят от проекта. @jpaugh - Я бы сказал, что у вас гораздо больше шансов установить вредоносное ПО, загрузив исполняемый файл - вредоносное ПО редко бывает открытым. Предполагая, что вы действительно можете читать язык. Я частично компилирую вещи на Linux, и я не могу читать / не читать ни одного источника. Даже если бы я мог, я не собираюсь пересматривать каждый.Файлы .c и .h имеют исходный код на языке C.
Вам нужно будет установить компилятор C, такой как Visual Studio, tcc или что-то подобное, загрузить проект и затем скомпилировать его для запуска.
В противном случае у проекта есть страница релиза ( здесь ), которая даст вам доступ к предварительно скомпилированной версии, чтобы сэкономить ваше время и усилия.
Если он должен был скомпилировать его, то это обычно объясняется в файле readme, который вы даже не упоминаете, что он должен искать. Он предназначен для перехода на страницу релиза, он не просто «отказывает (установка компилятора), он должен перейти на страницу релиза» Конкретный проект обычно настраивается для использования с определенным набором инструментов компиляции (называемым «цепочкой инструментов»), который обычно упоминается в файле readme (в UNIX и кроссплатформенных проектах он обычно называется BUILD или INSTALL) , В менее чем звездно поддерживаемых проектах или проектах для сред с несколькими известными наборами инструментов пользователь должен угадывать по формату и / или содержимому файлов проекта.Этот ответ будет касаться общего вопроса о создании приложения Windows только для исходного кода (на языке C). Если вам повезло, как OP, вы можете найти предварительно скомпилированные двоичные файлы.
Первое, о чем следует знать, это то, что нет единого способа создать приложение из исходного кода. Вариантов примерно столько же, сколько разных проектов. Тем не менее, вот несколько общих шагов:
Если вам повезет, проект предоставит инструкции по сборке, обычно внутри README файла. Иногда может также существовать INSTALL файл или другая доступная документация. Если таковые имеются, следуйте инструкциям. Это ваша лучшая ставка.
Как уже говорили другие, к сожалению, очень сложно восстановить необходимые этапы сборки без инструкций. Тем не менее, мы можем, по крайней мере, сделать попытку изо всех сил здесь, которая будет работать для большинства простых проектов.
В отсутствие инструкций следующий порт захода - проверить, какой инструмент сборки необходим.
Если вы найдете файл с расширением .sln или .vcxproj , это, вероятно, проект MSBuild / Visual Studio. Загрузите копию Visual Studio Community или Express (для C ++), откройте там этот файл проекта и нажмите кнопку воспроизведения на панели инструментов (или воспользуйтесь меню сборки).
Если вы найдете Makefile , это, вероятно, потребует make . Но здесь все становится еще сложнее, поскольку используется так много независимых и несовместимых систем make .
Поскольку он нацелен на Windows, он, вероятно, будет использовать MinGW . Загрузите его копию, запустите MSYS из меню «Пуск», перейдите ( cd ) в каталог, в котором находится ваш проект, и запустите make .
В редких случаях, когда вместо этого используется Cygwin (к сожалению, нет простого способа узнать, но если MinGW создает ошибки с ошибкой, связанной с «posix», это достойная ставка), вам придется вместо этого установить Cygwin . К сожалению, это не создает собственные двоичные файлы Windows - вам придется каждый раз запускать программу через Cygwin.
«Инструмент сборки» может представлять собой пользовательский сценарий по имени build.bat или аналогичный. В этом случае вам придется либо открыть его и посмотреть, что внутри, либо попробовать запустить его и посмотреть, в чем заключаются ошибки. Если вы откроете его и увидите упоминания GCC , вернитесь к 2.2.1. Шаг MinGW, но запустите пользовательский скрипт вместо make .
Возможно, что нет никакого инструмента для сборки вообще. Если все, с чем вы сталкиваетесь, - это отдельный файл .c или .cpp файл, то, вероятно, достаточно просто, чтобы вы могли выполнить прямую компиляцию. Это, опять же, почти всегда MinGW , поэтому загрузите его, запустите оболочку MSYS, перейдите в каталог и вызовите либо, gcc либо по g++ мере необходимости, например gcc -o program.exe program.c
Инструменты сборки
Инструмент для сборки позволяет строить проект с очень мало команд. Для большинства проектов с более чем одним исходным файлом где-то будет задействован инструмент сборки. Существует несколько инструментов сборки, но наиболее распространенными являются:
make , используется повсеместно в Linux и все чаще встречается в Windows. Использование проектов make обычно можно определить по наличию Makefile .
MSBuild специфичен для Windows и обычно рассматривается в сочетании с Visual Studio. Обычно они сопровождаются файлом *.sln или *.vcxproj файлом.
компилированные инструменты
Набор инструментов является компилятор и вспомогательные инструменты. Как и у инструментов сборки, их несколько, и они обычно используются с одним из инструментов сборки.
MSVC - это набор инструментов Microsoft. Это наиболее распространенный набор инструментов для разработки Windows. Это обычно используется с системой MSBuild, а сборки обычно создаются с помощью Visual Studio. Тем не менее, современные проекты MSVC можно использовать Makefile тоже.
GCC ( MinGW ) - это порт GCC для Windows. Обычно используется с make . Если проект изначально ориентирован на Windows и имеет Makefile , вероятно, для MinGW-GCC.
GCC ( Cygwin ) создает POSIX-совместимую среду. Это позволяет напрямую компилировать большинство программ, написанных для Linux или Unix, и работать напрямую под Windows. Совсем недавно в Windows 10, Bash на Ubuntu на Windows является альтернативой. GCC обычно используется в сочетании с make .
Каркасы и библиотеки
Библиотеки - это повторно используемые наборы кода, написанные другими людьми, от которых зависят многие программы, чтобы не изобретать велосипед. Вы должны иметь эти зависимости, доступные для построения проекта. Если вам повезет, они будут включены в вашу первоначальную загрузку, но это не всегда так.
Фреймворки - это фактически коллекция библиотек. Многие проекты используют один фреймворк, который вам также понадобится. Они также часто имеют собственную систему сборки, но перечислить их все было бы невозможно.
Самое сложное - это работа с дополнительными фреймворками и библиотечными зависимостями. Если, скажем, проект использует Qt - тогда вам понадобится весь этот беспорядок, чтобы правильно его построить. Это огромная задача, и если у вас нет опыта, вероятно, лучше просто попросить других о прямой помощи здесь.
Читайте также: