RPM пакеты имеют собственную структуру, отличную от других. Но зачем создавать свои RPM, если можно просто скомпилировать исходники? Ответ на этот вопрос в рутинной установке, а также помощи разработчикам Fedora или другим дистрибутивам. Устанавливая каждый раз одни и те же программы из исходников, можно написать скрипт для автоматизации этого, однако, если есть RPM, то не надо тратить много времени на установку, также как и необходимая программа будет постоянно доступна онлайн из репозитория (конечно же, если вы ее туда отправите).
Итак приступим к подготовке рабочей среды для создания RPM.
# yum groupinstall «Development Tools»
# yum install rpmdevtools
На данной стадии происходит установка необходимых утилит и различных библиотек разработчика.
НИКОГДА НЕ СОЗДАВАЙТЕ RPM ОТ ROOT! (это может нарушить работу системы, увеличить возможность взлома и так далее)
После окончания установки, запустите
rpmdev-setuptree
Это приведет к создание ветки директорий
Linux: сборка пакетов из исходников
BUILD BUILDROOT RPMS SOURCES SPECS SRPMS
Из всех директорий нас интересует только SOURCES SPECS, информация в остальных, если все сделано верно, сгенерируется автоматически.
Теперь нам нужен .spec файл, примеры можно найти путем стачивания .src.rpm с репозитория, после распаковки, будет .spec файл, который необходимо поправить под наши нужды.
Сами исходники с патчами или без, копируем в SOURCES.
Когда все готово, запускаем компилирование и создание RPM
rpmbuild -ba ПУТЬ/NAME.spec для создания .src.rpm
rpmbuild -bi ПУТЬ/NAME.spec для создания бинарника или просто .rpm
Для установки и/или тестирования
# rpm -ivh sourcepackage-name*.src.rpm
или
# rpm -ivh package-name*.rpm
Если все сделано правильно, то программа установится с предупреждением, что rpb database изменена сторонней программой (правильно, мы же ее еще не залили на Fedora сервер).
Объяснение часто используемых областей в .spec файле
Name: Базовое имя пакета удовлетворяющее требованиям Packagen Naming Guidelines. После этого, макрос % будет обращаться к данному разделу.
Version: Номер версии, при использовании даты в версии, используйте формат, гг.мм (пример 11.02). % для последующего обращения к данной области.
Release: Должно быть 1% , таким образом, число будет увеличиваться каждый раз, когда создается пакет для одной и той же версии дистрибутива.
Summary: Краткое описание пакета.
Group: Существующая группа пакетов, например Applications/Databases.
Чтобы узнать весь список
# less /usr/share/doc/rpm-*/GROUPS
Для документации будет соответственно группа Documentation.
License: Лицензия на программу, обязана быть для открытых исходников, например «GPLv2+» (GPL версии 2 или новее). Для нескольких лицензий используйте «and» или «or» «GPLv2 and BSD». Следует указывать лицензию максимально точно, можно указывать несколько лицензий с помощью «and» и «or», например «GPLv2 and BSD».
5 причин научиться собирать софт из исходников
URL: Ссылка на сайт программы/проекта.
Source0: Ссылка на архив с исходным кодом. Если указана полная ссылка, то одноименный пакет должен быть в папке SOURCES. Если источников исходного кода несколько, то используем Source1, Source2 и т.д.
Patch0: Название первого патча для программы, имя файла должно заканчиваться на .patch и лежать в директории ~/rpmbuild/SOURCES. Патчей может быть несколько.
BuildArch: Архитектура программы под определенные процессоры. Для универсальных пакетов «noarch».
BuildRoot: Место, выделенное для компиляции и установки исходников приложения во время выполнения процесса «%install». По стандарту Fedora, будет создана специальная директория в /var/tmp. Более новые версии RPM пропустят это значение и поместят build root в %/BUILDROOT/
BuildRequires: Список необходимых приложений для сборки пакета (через запятую). Автоматически не определяются. Некоторые стандартные приложения могут быть опущены в данном списке. Полный список приложений, которые могут быть пропущены здесь (https://fedoraproject.org/wiki/Packaging/Guidelines).
Requires: Список необходимых приложений для работы после установки (через запятую). В большинстве случаев определяются автоматически rpmbuild.
%description: Описание программы, строки не должны быть длиннее 80 символов.
%prep: Скрипты для подготовки программы, распаковки и подготовки к сборке.
%build: Скрипты для сборки программы, компиляции и подготовки к установке.
%test: Скрипты для тестирования программы, выполняются после %build, но до %install.
%install: Скрипты для установки программы, команды скопируют файлы из «build directory» % (которая находится ~/rpmbuild/BUILD) в директорию buildroot %, которая обычно находится в /var/tmp.
%clean: Инструкции для очистки buildroot, например,
rm -rf %
%files: Список устанавливаемых файлов.
%changelog: Изменения в программе.
Статья подготовлена опираясь на официальный источник от Fedora
Источник: linuxnow.ru
Практическое руководство. Создание проекта C++ из существующего кода
В Visual Studio существующие файлы кода можно перенести в проект C++ с помощью мастера создания проектов из существующих файлов кода. Этот мастер создает проект, использующий систему MSBuild для управления исходными файлами и конфигурацией сборки. Лучше всего она работает с относительно простыми проектами, в которых нет сложных иерархий папок. Мастер недоступен в более старых выпусках Visual Studio Express.
Перенос существующих файлов кода в проект C++ позволяет использовать собственные функции управления проектами MSBuild, встроенные в интегрированную среду разработки. Если вы предпочитаете использовать существующую систему сборки, например файлы makefile NMake, CMake или альтернативные варианты, вместо этого можно использовать функцию «Открыть папку» или средство CMake. Дополнительные сведения см. в статьях Проекты «Открыть папку» в C++ или Проекты CMake в Visual Studio. Оба варианта позволяют использовать возможности интегрированной среды разработки, такие как IntelliSense и Свойства проекта.
Создание проекта C++ из существующего кода
Установите флажок Добавить вложенные папки, чтобы файлы кода копировались в проект из всех подкаталогов. Каталоги перечислены в столбце Папка.
— Выберите Добавить, чтобы отобразилось диалоговое окно Добавление файлов в проект из этой папки, чтобы указать каталоги в которых мастер будет искать существующие файлы кода.
— Выберите Удалить, чтобы удалить путь к каталогу, выбранный в списке.
Выберите Тип проекта, чтобы указать тип проекта, создаваемого мастером. Выберите Проект приложения Windows, Проект консольного приложения, Проект библиотеки DLL или Проект статической библиотеки (LIB) .
Установите флажок Добавить поддержку для ATL, чтобы добавить ее в новый проект.
Установите флажок Добавить поддержку для MFC, чтобы добавить ее в новый проект.
Примечание Если установлен флажок Использовать внешнюю систему сборки, интегрированная среда разработки не создает проект, поэтому параметры /D, /I, /FI, /AI и /FU для компиляции не требуются. Однако эти параметры должны быть заданы правильно для надлежащей работы IntelliSense.
Задайте нужные параметры отладочной конфигурации. Чтобы продолжить, нажмите кнопку Далее .
| Командная строка для сборки | Указывает командную строку для сборки проекта. Введите имя компилятора (а также все параметры или аргументы) либо скрипты сборки, которые вы хотите использовать для сборки проекта. |
| Командная строка перестроения | Указывает командную строку, которая перестраивает новый проект. |
| Командная строка для очистки | Указывает командную строку для удаления вспомогательных файлов, создаваемых средствами сборки для проекта. |
| Вывод (для отладки) | Указывает путь к каталогу выходных файлов для конфигурации отладки проекта. |
| Определения препроцессора (/D) | Определяет символы препроцессора для проекта. См. раздел /D (определения препроцессора). |
| Путь поиска включаемых файлов (/I) | Указывает пути к каталогам, где компилятор будет производить поиск для разрешения ссылок на файлы, переданных в директивы препроцессора в проекте. См. раздел /I (дополнительные включаемые каталоги). |
| Принудительно включенные файлы (/FI) | Указывает файлы заголовков, которые нужно обрабатывать при сборке проекта. См. раздел /FI (задание имени обязательно включаемого файла). |
| Пути для поиска сборки .NET (/AI) | Указывает пути к каталогам, где компилятор будет производить поиск для разрешения ссылок на сборки .NET, переданных в директивы препроцессора в проекте. См. раздел /AI (указание каталогов метаданных). |
| Принудительно использовать сборки .NET (/FU) | Указывает сборки .NET, которые нужно обрабатывать при сборке проекта. См. раздел /FU (задание имени обязательного файла #using). |
Примечание Команды Создать, Перестроить, Очистить и параметры Выходные данные (для отладки) включены, только если на странице Указание параметров проекта задан параметр Использовать внешнюю систему сборки.
Примечание Здесь вы можете установить флажок Совпадает с конфигурацией отладки: он укажет, что мастер будет создавать параметры для конфигурации выпуска, аналогичные параметрам проекта для конфигурации отладки. Этот параметр выбран по умолчанию. Пока этот флажок установлен, все остальные параметры на этой странице неактивны.
Источник: learn.microsoft.com
Введение в CMake
CMake — кроcсплатформенная утилита для автоматической сборки программы из исходного кода. При этом сама CMake непосредственно сборкой не занимается, а представляет из себя front-end. В качестве back-end`a могут выступать различные версии make и Ninja. Так же CMake позволяет создавать проекты для CodeBlocks, Eclipse, KDevelop3, MS VC++ и Xcode. Стоит отметить, что большинство проектов создаются не нативных, а всё с теми же back-end`ами.
Для того что бы собрать проект средствами CMake, необходимо в корне дерева исходников разместить файл CMakeLists.txt, хранящий правила и цели сборки, и произвести несколько простых шагов.
Разберёмся на примерах.
Пример 1. Hello, World:
Для начала напишем простейший хеловорлд и создадим структуру проекта:
main.cpp
#include int main(int argc, char** argv)
CMakeLists.txt
cmake_minimum_required(VERSION 2.8) # Проверка версии CMake. # Если версия установленой программы # старее указаной, произайдёт аварийный выход. add_executable(main main.cpp) # Создает исполняемый файл с именем main # из исходника main.cpp
Синтаксис CMake похож на синтаксис bash, всё что после символа «#» является комментарием и обрабатываться программой не будет. CMake позволяет не засорять дерево исходных кодов временными файлами — очень просто и без лишних телодвижений сборка производится «Out-of-Source».
Создадим пустую директорию для временных файлов и перейдём туда.
Теперь запустим команду cmake, передав ей в качестве параметра путь к папке с исходниками:
Видим, что в папке появилось несколько временных файлов, необходимых для сборки проекта.
Теперь можно запустить непосредственно make:
Итак, наша программа собралась.
Папку tmp можно очищатьудалять без риска поломать исходники. Если CMakeLists.txt был изменен, то вызов make автоматически запустит cmake. Если исходники были перемещены, то нужно очистить временную директорию и запустить cmake вручную.
Пример 2. Библиотеки:
Если ваш проект содержит библиотеку, то CMake соберет ее без проблем.
Для этого усложним пример.
void hello_world();
foo.cpp
#include void hello_world()
main.cpp
#include «foo.h» int main(int argc, char** argv)
CMakeLists.txt
cmake_minimum_required(VERSION 2.8) # Проверка версии CMake. # Если версия установленой программы # старее указаной, произайдёт аварийный выход. project(hello_world) # Название проекта set(SOURCE_EXE main.cpp) # Установка переменной со списком исходников для исполняемого файла set(SOURCE_LIB foo.cpp) # Тоже самое, но для библиотеки add_library(foo STATIC $) # Создание статической библиотеки с именем foo add_executable(main $) # Создает исполняемый файл с именем main target_link_libraries(main foo) # Линковка программы с библиотекой
Переменные могут хранить списки значений, разделённых пробеламитабуляциямипереносами:
set(SOURCE main.cpp foo.cpp) set(HEADER main.h foo.h)
Оба варианта правильные
Что бы получить значение переменной ипользуем конструкцию:
Итак, эта версия нашего проекта включает в себя одну статическую библиотеку, собираемую из исходников. Если заменить «STATIC» на «SHARED», то получим библиотеку динамическую. Если тип библиотеки не указать, по умолчанию она соберётся как статическая.
При линковке указываются все необходимые библиотеки:
target_link_libraries(main foo ogg vorbis)
Как и при ручной компиляции, имена библиотек указываются без стандартного префикса «lib».
Итак, сборка библиотек с CMake не вызывает проблем, при этом тип библиотеки статическаядинамическая меняется лишь одним параметром.
Пример 3. Подпроекты:
Подпроекты очень удобны, если ваша программа разбита на несколько библиотек или же проект состоит из нескольких программ.
Каждый подпроект является по сути полноценным проектом и может использоваться самостоятельно.
Теперь у нас «foo» находится в субдирректории и там же находится CMakeLists.txt подпроекта.
CMakeLists.txt
cmake_minimum_required(VERSION 2.8) # Проверка версии CMake. # Если версия установленой программы # старее указаной, произайдёт аварийный выход. project(hello_world) # Название проекта set(SOURCE_EXE main.cpp) # Установка переменной со списком исходников include_directories(foo) # Расположение заголовочных файлов add_executable(main $) # Создает исполняемый файл с именем main add_subdirectory(foo) # Добавление подпроекта, указывается имя дирректории target_link_libraries(main foo) # Линковка программы с библиотекой
main.cpp
#include «foo.h» int main(int argc, char** argv)
foo/CMakeLists.txt
cmake_minimum_required(VERSION 2.8) # Проверка версии CMake. # Если версия установленой программы # старее указаной, произайдёт аварийный выход. project(foo) # Название проекта set(SOURCE_LIB foo.cpp) # Установка переменной со списком исходников add_library(foo STATIC $)# Создание статической библиотеки
foo/foo.h
void hello_world();
foo/foo.cpp
#include void hello_world()
В файле подпроекта ничего нового для вас нет. А вот в основном файле новые команды:
include_directories(foo)
main.cpp мы не меняли, а foo.h перенесли. Команда указывает компилятору, где искать заголовочные файлы. Может быть вызвана несколько раз. Хидеры будут искаться во всех указаных директориях.
add_subdirectory(foo)
Указываем директорию с подпроектом, который будет собран как самостоятельный.
Вывод: проекты на CMake можно объединять в довольно сложные иерархические структуры, причем каждый подпроект в реальности является самостоятельным проектом, который в свою очередь может сам состоять из подпроектов. Это позволяет легко разбить вашу программу на необходимое количество отдельных модулей. Примером такого подхода может служить KDE.
Пример 4. Поиск библиотек:
CMake обладает достаточно развитыми средствами поиска установленых библиотек, правда они не встроеные, а реализованы в виде отдельных модулей. В стандартной поставке довольно много модулей, но некоторые проекты (например Ogre) поставляют свои. Они позволяют системе автоматически определить наличие необходимых для линковки проекта библиотек.
На debian модули располагаются в /usr/share/cmake-2.8/Modules/ (у вас версия может отличаться). За поиск библиотек отвечают модули, называющиеся FindNAME.cmake, где NAME — имя библиотеки.
find_package(SDL REQUIRED) if(NOT SDL_FOUND) message(SEND_ERROR «Failed to find SDL») return() else() include_directories($) endif() ########################################################## find_package(LibXml2 REQUIRED) if(NOT LIBXML2_FOUND) message(SEND_ERROR «Failed to find LibXml2») return() else() include_directories($) endif() ########################################################## find_package(Boost COMPONENTS thread-mt REQUIRED) if(NOT Boost_FOUND) message(SEND_ERROR «Failed to find boost::thread-mt.») return() else() include_directories($) endif() ########################################################## target_link_libraries($ $ $ $)
Думаю, смысл должен быть понятен. Первый и второй блок — поиск библиотеки. Если в системе её нет, выведется сообщение об ошибке и завершается выполнение cmake. Третий блок похож, только он ищет не целый пакет библиотек, а лишь необходимый компонент. Каждый такой автоматизированый поиск определяет после выполнения как минимум 3 переменные:
SDL_FOUND, LIBXML2_FOUND, Boost_FOUND — признак присутствия бибилиотеки;
SDL_LIBRARY, LIBXML2_LIBRARIES, Boost_LIBRARIES — имена библиотек для линковки;
SDL_INCLUDE_DIR, LIBXML2_INCLUDE_DIR, Boost_INCLUDE_DIRS — пути к заголовочным файлам.
Если с первыми более или менее понятно, то вторые и третьи мне доставили много хлопот — половина имеет имена в единственном числе, половина — во множественном. Но оказалось, это легко отследить. В каждом модуле вначале есть коментарии, там описаны определяемые переменные. Посмотрите, например, /usr/share/cmake-2.8/Modules/FindLibXml2.cmake
Как видите, CMake способен сам определить наличие и местоположение необходимых библиотек и заголовочных файлов. В принципе, это должна уметь любая система автоматической сборки, иначе смысл в ней?
Пример 5. Внешние библиотеки и объектные файлы:
Если вы пишите для «дяди», а злой «дядя» любит самописные библиотеки и делиться исходниками не желает, поэтому присылает готовую библиотеку, то вы по адресу.
Объектные файлы в CMake стоят на ряду с исходниками — достаточно включить объектник в список файлов для компиляции.
С библиотеками потуже. Как известно, статическая библиотека это не что иное, как ar-архив, внутри которого лежат обычные объектники, никак не связаные между собой. Вы, наверное, уже догадались, как я поступал сначала. Да, просто потрошил библиотеку. Но потом был найден способ поэлегантнее:
add_library(netutil STATIC IMPORTED) set_property(TARGET netutil PROPERTY IMPORTED_LOCATION Binary/game_client/libnetutil.a)
Слово «IMPORTED», указывает, что библиотека берётся извне.
В CMake каждая цель имеет параметры, а set_property позволяет их изменять.
Линкуется такая библиотека стандартно:
target_link_libraries($ netutil)
Для динамических библиотек все аналогично, только тип «SHARED», расширение — «.so».
К сожалению, поддержка несистемных библиотек реализована немного костыльно. Возможно, я просто не знаю правильного варианта, поэтому буду рад, если «ткнете мордочкой». С другой стороны это не навороченый экзоскелет с системой жизнеобеспечения, а простейший костыль из двух строк.
Генераторы:
Как было сказано в начале, CMake умеет генерировать множество различных видов проектов. Это удобно и позволяет использовать CMake для практически любой популярной IDE.
Если запустить cmake без параметров, в конце будут описаны доступные генераторы. Пользоваться так:
Заключение:
Это не перевод мануала, а результат использования CMake в одном коммерческом проекте. Буду рад, если статья поможет хотя бы одному человеку — на русском языке подобной документации довольно мало.
- один проект — один файл. Не нужно хранить кучу скриптов настройки, сборки и прочего хлама;
- Скорость работы в сравнении с autotools;
- простой и понятный синтаксис, конечно с элегантностью питона не потягаться, но и не брейнфак, в конце концов.;
- является front-end`ом для множества IDE;
- отображение прогресса — довольно удобно;
- цветной вывод — в серые будни немного краски не помешает;
Источник: habr.com