Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Сборка проектов c

Сборка проекта под Windows, Linux и MacOS и тестирование

Есть приложение с графическим интерфейсом которое нужно собрать под поддерживаемые версии Windows, Linux и MacOS и протестировать их на указанных платформах (32 и 64 бит).

Известные мне варианты:
1) Установить все нужные ОС, собрать на них проект и протестировать приложение
2) Либо собрать проект на одной ОС (но так что бы бинарники были и для остальных).
Далее перебросить бинарники на указанные ОС и тестировать там

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

Рабочая ОС — CentOS 7.
Проект на Qt.
Спасибо.

Сборка проекта под MacOS работая на Windows
Каким образом можно собрать проект под MacOS, если я сижу на Windows и виртуальную машину с Mac-ом.

Сборка проекта C# под MacOS
Приветствую! Есть проект на c#, использую micosoft visual studio, появилась необходимость собрать.

Сборка проекта под Linux
Есть проект. Написан в Visual Studio, под Windows. Сейчас появилась необходимость собирать проект в.

Qt сборка проекта под Linux
Здравствуйте! Имею проект написанный из под Windows. Хочу собрать debug-сборку под Linux.

Жиза

Добавлено через 6 минут

Решение

Continuous Integration к вашим услугам

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

Классика жанра: «инспекция кода» -> «сборка» -> «тестирование» -> «выгрузка продукта»

Причем, в зависимости от особенностей конкретной CI,
сборка-тестирование может осуществляться на всех интересующих вас платформах.
То бишь, разработчики сервиса уже заранее подсуетились насчет различных ОС,
и компиляторов.

Вам просто нужно погуглить, и подыскать подходящий для вас.

На гитхабе travis уважают

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

Обратите внимание на красивую табличку » build|passed »
Это — кросс-ссылка на сервис CI,
где собственно и производится сборка/тестирование данного проекта.

Так же, услуги CI предлагает gitlab
Там вообще можно весь цикл разработки организовать для крупной софтверной компании.
Начиная от хостинга проектов, заканчивая деплоем для конечных пользователей.
Так же есть инструменты для управления проектами
(баг-треккер, проектирование, слежение за ходом выполнения задач)

Изначально, gitlab — это open source альтернатива github,
с нативной поддержкой CI, но в итоге у них получился мощный комбайн,
который умеет все, что только может понадобится софтверной компании.

Так как он open source, то его можно развернуть на своём собственном хосте,
и осуществлять какой угодно менеджмент проектов,
применяя CI-сценарии любой сложности.

Сама им пользуюсь. Очень удобная вещь)
Рекомендую))

Многофайловые сборки

Многофайловая сборка — это коллекция взаимосвязанных модулей, которые развертываются и снабжаются версией в виде цельной логической единицы. В IDE-среде Visual Studio никакого отдельного шаблона проекта для создания многофайловой сборки на C# не предусмотрено. Для создания такового пока что должен использоваться компилятор командной строки (csc.exe).

Рассмотрим этот процесс на примере, создав многофайловую сборку по имени Car. В главном модуле этой сборки (car.dll) будет содержаться единственный тип класса SportCar и соответствующий манифест, который указывает на наличие дополнительного файла *.netmodule по имени auto.netmodule, содержащего еще один класс Auto. Хотя физически оба класса размещаются в отдельных двоичных файлах, пространство имен у них будет одно — Car. И, наконец, оба класса будут создаваться на C# (хотя, конечно же, вполне допустимо использовать другие языки). Для начала откроем простой текстовый редактор и создадим следующее определение для класса Auto, после чего сохраним его в файле с именем auto.cs:

Чтобы скомпилировать этот класс в .NET-модуль, откройте в Visual Studio 2010 окно командной строки, перейдите в папку, где был сохранен файл auto.cs, и введите следующую команду (опция module флага /t указывает, что должен быть создан файл *.netmodule, а не *.dll или *.ехе):

В папке с файлом auto.cs появится новый файл по имени auto.netmodule. Теперь давайте создадим новый файл sportcar.cs со следующим определением класса:

Поскольку было решено, что главный модуль в этой многофайловой сборке будет называться car.dll, осталось только скомпилировать sportcar.cs с использованием соответствующих опций /t: library и /out:. Чтобы включить информацию о двоичном файле auto.netmodule в манифест сборки, также потребуется добавить соответствующий флаг /addmodule. Полностью необходимая команда выглядит следующим образом:

Читать еще:  Не пикает биос при включении

После выполнения этой команды в каталоге должен появиться главный модуль car.dll, а также второстепенный двоичный файл auto. netmodule.

Теперь откроем файл auto.netmodule в утилите ildasm.exe. Сразу же можно будет заметить, что в нем содержится манифест уровня модуля, единственной задачей которого является перечисление всех внешних сборок, которые упоминаются в кодовой базе. Поскольку в классе Auto был практически добавлен только вызов Console.WriteLine(), обнаружится следующая ключевая информация:

Далее откроем в ildasm.exe файл главного модуля car.dll и изучим содержимое манифеста уровня всей сборки. В нем важно обратить внимание, что маркер .file используется для представления информации о других ассоциируемых с многофайловой сборкой модулях (в данном случае — auto.netmodule), а маркеры .class extern — для перечисления имен внешних типов, которые упоминаются как используемые во второстепенном модуле (в данном случае — Auto). Ниже приведена соответствующая информация:

Использование многофайловой сборки

Пользователям многофайловой сборки нет никакого дела до того, состоит ли сборка, на которую они ссылаются, из многочисленных модулей. Чтобы не усложнять пример, построим новое клиентское приложение на языке C# в командной строке. Для начала создадим новый файл по имени Client.cs со следующим определением модуля и сохраним его в месте, где находится многофайловая сборка:

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

Обратите внимание, что при добавлении ссылки на многофайловую сборку компилятору необходимо указать только имя главного модуля (второстепенные модули *.netmodule будут загружаться CLR-средой по требованию, когда возникнет необходимость в их использовании клиентским кодом). Сами по себе модули *.netmodule не обладают никаким индивидуальным номером версии и потому не могут напрямую загружаться CLR-средой. Отдельные модули *.netmodule могут загружаться только главным модулем (например, файлом, в котором содержится манифест сборки).

Сборка c++ проекта

Добрый день! Хочется чего то такого эдакого, решил закостылить свой stomp сервер в качестве хобби на c++, с плюсами дела ранее не имел, проект хочу маленький без всяких монструозных библиотек и фреймворков. Для работы с сетью возьму boost.asio (альтернативы?). Вопрос — как сегодня нормальные люди собирают c++ проекты? А тестируют как? В java все просто — взял maven + junit и все хорошо, а в суровом мире бородачей как обстоят дела?

cmake (не рекомендую заморачиваться с CTest, удобнее пускать итоговые бинари тестов руками)

boost.test/gmock/catch => unit, лично я предпочитаю gmock, но в boost.test тоже есть свои вкусности и оно вместе с буст идёт, но нет mock/stub/fake из коробки.

python => acceptance, сетевые сервера очень удобно тестировать из питон скриптов, вне зависимости от того, на чем они написаны

Чтобы два раза не вставать, в качестве ide порекомендую QtCreator 🙂

Cmake, в качестве либы для тестинга я юзаю gtest, но если буст тянешь, то имеет смысл поюзать Boost.Test. Ещё вот модно сейчас Conan обмазываться, чтобы тому, кто захочет твой проект собрать у себя, не пришлось мучиться с зависимостями — conan постарается всё разрулить.

IDE выбор неважен, в принципе. Каждый пишет ровно на том, что ему удобно.

Большое спасибо за задание направления, это действительно полезно для меня 🙂

Для работы с сетью возьму boost.asio

Asio Standalone можно взять, чтоб boost_system не тащить

cmake + ctest. В качестве тест фреймворка я юзаю самописный хедер на две страницы, а так бы взял что-то похожее типа catch. gtest/boost — ненужная жирнота.

Для тестов gtest, который с полпинка интегрируется с cmake

Если в качестве тестового фреймворка будет выбран gmock/gtest настоятельно рекомендую ознакомиться с рекомендоваными механизмами подключения к проекту. В частности в cmake лучше подключать либо в виде cmake подпроекта (а не как либу и набор хидеров) либо как gtest-all.[h]|[cpp]. Не просто так там нету цели install в этих фреймворках, но многие прыгают по граблям.

Сборка cmake (как уже отписались многие). Тесты gtest/gmock. Собираю как их как подпроект cmake и получаю пару библиотек gtest_main/gmock_main (в этих библиотеках и определена функция main запускающая тестовые кейсы), бинарник теста линкую с gmock_main. Запуск тестов через CTest (это часть cmake). В качестве IDE QtCreator. С cmake дружит, тесты одним хоткеем запускает. Если сетевой IO предполагается асинхронный, то имеет смысл посмотреть на libuv + враппер uvw (https://github.com/skypjack/uvw).

Большие волосатые дяди используют Cmake, но ребятня вроде меня использует qmake (+Qt Creator IDE). От фреймворков отказываешься напрасно, думаешь пользователь оценит малокилобайтность твоей программы?

Сборка проекта

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

Читать еще:  Биос не видит оперативную память

Автоматизация процесса сборки программного продукта связана с разработкой различных скриптов для выполнения таких действий, как :

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

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

Таким образом, автоматизация процесса сборки проекта становится неотъемлемой частью процесса разработки. С развитием интегрированных средств разработки (IDE Eclipse, NetBeans, IntelliJ IDEA и т.п.) стало ясно, что пакетные файлы для автоматизации сборки уже не соответствуют современным требованиям. Появились новые системы автоматизации сборки Apache Ant, Apache Maven.

Apache Ant (http://ant.apache.org) сталлогическим продолжением make, схожий по принципу работы инструмент, основной задачей которого была обеспечить автоматизацию процесса сборки Java приложений. Ant — это императивная командная система, созданная для кроссплатформенного применения. Изначально ant разрабатывался для сборки и компановки java-проектов.

Для java-разработчиков большой проблемой применения пакетных файлов было то, что они сильно завязаны на команды операционной системы (OC). В случае, если необходимо было обеспечить сборку проекта в разных операционных системах, то нужно было использовать не только разные наборы и параметры команд, но и формат командных файлов. Разработка собственного командного файла сборки под каждую платформу – это не лучший выбор для кроссплатформенных приложений. В результате Apache Ant был спроектирован таким образом, что часто применяемые при сборке команды ОС обернуты внутренними командами ant, а скрипты сборки описываются в формате XML.

Широкое распространение получила декларативная система автоматизации сборки Apache Maven согласно описанию проектного pom.xml файла формата XML. В файлах проекта pom.xml содержатся не отдельные команды, а описание проекта. Все задачи по обработке файлов maven выполняет с использованием плагинов.

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

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

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

Личный опыт разработки ПО

Сборка проектов с CMake. Введение

Для автоматизации сборки проектов традиционно используют системы сборки, такие как make на Unix подобных системах и nmake для компилятора Microsoft. Также традиционно написание файлов для сборки проекта под эти системы является задачей нетривиальной. Конечно в пользуясь только Mictosoft Visual Studio можно даже не подозревать о существовании этих файлов, так как интегрированная среда разработки достаточно удобно скрывает всю кухню, оставляя снаружи несколько диалоговых окон и кнопку Build. Но для сложных проектов использующих массу сторонних библиотек и кроссплатформенных проектов такой подход часто оказывается неприемлемым.

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

Что нужно сделать?

Собрать программу hello_world.

Как ее делать?

Взять файлы hello_world.h и hello_world.cpp и запустить компилятор передав их в качестве параметров.

Что делать когда компилятор закончит работать?

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

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

Читать еще:  Как настроить вращение кулера в биосе

Выглядит все просто, проблемы возникают дальше и проблем несколько:

  1. Разрешение зависимостей возникающих между частями проекта
  2. Синтаксическая сложность и неоднозначность классических make-файлов
  3. Привязка к конкретной утилите автоматической сборки и как следствие непереносимость на другие платформы

Для решения части этих проблем или всех сразу были созданы следующие инструменты: Automake (http://sourceware.org/automake/) , CMake (http://www.cmake.org/), SCons (http://www.scons.org/). Список далеко не полный.

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

Сам CMake не осуществляет сборку проекта, он лишь генерирует из своего файла сборки make-файл для конкретной платформы. Это может быть проект Microsoft Visual Studio, NMake makefile, проект XCode для MacOS, Unix makefile, Watcom makefile, проект Eclipse или CodeBlocks. Более того файлы CMake открывает как проект набирающая популярность среда разработки QtCreator.

Данный файл обычно называется CMakeLists.txt и содержит команды понятные CMake. Выполнив

Мы получим либо проект который можно открыть в вашей среде разработки, либо makefile по которому можно собрать проект запустив соответствующую систему сборки (make, nmake, wmake). Всегда можно явно указать, что должна генерировать программа, указав ключ –G с нужным параметром (просто запустите cmake, чтобы увидеть доступные варианты).

Где взять CMake?

Дистрибутив CMake можно скачать с официального сайта (http://cmake.org/cmake/resources/software.html) где есть версии для всех популярных платформ или установить из репозитория вашего дистрибутива Linux, скорее всего он там уже есть.

Hello, World!

Предлагаю рассмотреть простой CMake-файл:

Что здесь происходит?

  1. В первой строке просто указана минимальная версия CMake необходимая для успешной интерпретации файла.
  2. В третьей строке определяется переменная PROJECT и ей задается значение hello_world — так будет называться наша программа.
  3. О чем и говорится в пятой строке. Конструкция $ <ИМЯ_ПЕРЕМЕННОЙ>возвращает значение переменной, таким образом проект будет называться hello_world.
  4. В седьмой и десятой строках вводятся переменные содержащие список файлов необходимых для сборки проекта.
  5. И в последней строке идет команда собрать исполняемый файл с именем указанном в переменной PROJECT и из файлов имена которых находятся в переменных HEADERS и SOURCES.

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

Как собрать библиотеку с CMake?

Точно также как и исполняемый файл, но в последней строке вместо команды add_executable, укажите команду add_library. В этом случае будет собрана статическая библиотека, для сборки динамической библиотеки надо указать параметр SHARED после имени библиотеки:

Немного о стиле

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

  • Имена переменных пишутся английскими буквами в верхнем регистре
  • Команды CMake записываются английскими буквами в нижнем регистре
  • Параметры команд CMake пишутся английскими буквами в верхнем регистре
  • Команды CMake отделены пробелом от открывающей скобки

Где должен находится CMakeLists.txt?

Очень удобно в корне каждого проекта иметь директорию build с файлами сборки проекта, причем имя файла во всех директориях должно называться одинаково (название по умолчанию CMakeLists.txt отлично подойдет). Это позволит собирать сложные проекты рекурсивно подключая директории с подпроектами (о подключении подпроектов к проекту можно прочесть в моей заметке).

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

Сборка сложного проекта

Усложним задачу и соберем проект зависящий от библиотеки. Для этого надо сделать следующие вещи:

  1. Собрать библиотеку
  2. Подключить библиотеку к проекту

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

Теперь о том как эту библиотеку подключить. Сделать это можно добавив в CMakeLists.txt проекта три строки:

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

Во второй строке идет указание CMake взять файл из директории build подпроекта, выполнить его и результат работы положить в директорию ./bin/ИМЯ_БИБЛИОТЕКИ.

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

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

Ссылка на основную публикацию
Adblock
detector