Главная страница » Как скомпилировать проект с github

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

  • автор:

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

БлогNot. Как собрать проект C++ с github из исходников и подключить его к Visual Studio

Как собрать проект C++ с github из исходников и подключить его к Visual Studio

Благодаря менеджеру пакетов winget, уже входящему в актуальные сборки масдайки, теперь в Windows 10 можно инсталлировать приложения одной простой консольной командой (см. также доку от Микрософта).

Но мы рассмотрим сейчас ситуацию, когда у нас есть только ссылка на исходники проекта, скажем, на Гитхабе (возьмём для примера библиотеку для простых чисел primesieve) и нужно каким-то образом скомпилировать внешний проект в своей Studio, чтобы воспользоваться его возможностями в своём приложении.

В противном случае, конечно же, нестандартный include вроде этого, который вы нашли в коде-образце

работать не будет ни за что.

Первым делом скачаем все исходники внешнего проекта «как есть» в архиве .zip, для этого у нас на гитхабе есть кнопка «Download ZIP»:

Как загрузить проект с github в архиве .zip
Как загрузить проект с github в архиве .zip

Развернём проект, не создавая новой папки, если у вашего архиватора нет такого же пункта меню, просто сотрите предлагаемое архиватором имя новой папки, потому что папка уже есть в архиве:

Извлечь внешний проект из архива, не создавая новой папки
Извлечь внешний проект из архива, не создавая новой папки

Если покопаться в файле readme.md проекта, как правило, можно найти инструкцию по установке (Build instructions) и даже «Detailed build instructions», где говорится, в числе прочего, и о компиляции проекта под Microsoft Visual C++:

Команды cmake для компиляции проекта со страницы документации
Команды cmake для компиляции проекта со страницы документации

Откроем свой «некомпилируемый» без нужной библиотеки проект в Studio (я использую актуальную сборку версии 2019) и обратимся к команде меню Вид — Терминал. Выберем инструмент «Командная строка разработчика» (по умолчанию в новых сборках теперь выбран PowerShell, впрочем, если в документации приведены команды PowerShell, то применяйте их).

У Микрософта инструмент описан вот здесь.

Командная строка разработчика в Studio
Командная строка разработчика в 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, вот сама программа:

Ответы вышли такие:

За счёт хорошо оптимизированного кода библиотеки считается всё мгновенно.

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, 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.

Toliak / Guide.md

Чтобы установить значение опции, отличное от «по умолчанию», необходимо дописать -DНАЗВАНИЕ_ОПЦИИ=Значение к команде конфигурирования. Команда после этого может выглядеть, например, так:

Чтобы сделать такое действие в CLion, необходимо перейти в: Settings -> CMake -> CMake options.

Если используется Hunter (пакетный менеджер), то прописываются его настройки

На этапе конфигурирования, CMake ожидает файл tools/gate/cmake/HunterGate.cmake .

Если этот файл не существует, возможны 2 варианта:

  • Необходимо добавить гит подмодуль:

git submodule add https://github.com/hunter-packages/gate.git tools/gate

  • Либо (если используется шаблонный репозиторий) необходимо обновить подмодули:

git submodule update —init —recursive

URL и SHA1 ядра Hunter можно получить в релизах: https://github.com/hunter-packages/gate.git

Дополнительные опции для компилятора (могут отсутствовать)

Подключение зависимых библиотек

Затем осуществляется подключение библиотек, в которых нуждается проект (Boost, GTest, Threads и т.д.)

Указания для Hunter о необходимо коллекционирования указанных пакетов

Указания о том, какие пакеты будут использованы (ожидается их наличие)

CONFIG — ключевое слово, показывающее маску названий конфигурационных файлов.

REQUIRED — обязательность подключения пакета (иначе — ошибка).

Добавление целей сборки

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

Указание директорий с заголовочными файлами

Указание библиотек для линковки

Названия библиотек из Hunter, как правило, имеют вид LibraryName::ComponentName .

Данные о библиотеках из пакета, добавленного через find_package хранятся в переменных. Например, для Threads: $

Для сборки тестирования необходимо наличие:

  1. Добавления пакета googletest (GTest в Hunter)
  2. Цели для сборки исполняемого файла
  3. Линковки gtest_main и gtest (GTest::main и GTest::gtest в Hunter) к цели
  4. Включенного тестирования в конфигурационном файле

Можно добавлять несколько тестовых целей под разными названиями. И даже с использованием разных фреймворков.

Для сборки и выполнения тестирования необходимо выполнить следующую команду (ожидается предварительное конфигурирование):

Пример тела конфигурационного файла с тестированием:

Для удобства в CLion необходимо добавить конфигурацию сборки google test.

Начало конфигурации. Как правило, его трогать не надо.

Далее прописываются цели, которые будут проанализированы на процент покрытия.

Конец конфигурации. Как правило, не надо трогать.

Для начала необходимо настроить окружение. Как правило, это не надо трогать

Далее необходимо указать jobs’ы, которые будет выполнять Travis. Jobs содержит название и команды.

К таким относятся, например, правила для веток и для уведомлений. Например:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *