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

Крайне полезная информация по переменным CMake находится по адресу http://www.cmake.org/Wiki/CMake_Useful_Variables. После прочтения сами собой отпадают многие вопросы.

Ну и напомню, что содержимое переменной XXX можно посмотреть:

message (${XXX})

И изменить:

set (XXX ${XXX} значение)

А также проверить присутствует ли в переменной определенная подстрока:

if (XXX MATCHES "подстрока")
	...
endif ()

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

string (REGEX REPLACE /W[0-4] /W4 CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})

В данном случае будет установлен максимальный уровень предупреждений /W4 для компилятора от Microsoft.

Некоторые интересуются, а как же у CMake со скоростью? Субъективно все достаточно быстро, если же говорить о цифрах, то один из разработчиков Quantum GIS приводит в своем блоге сравнение скорости сборки их проекта с CMake и с Autotools. Цифры конечно впечатляют – так хорошо, что даже странно. Смотрите сами:

http://blog.qgis.org/?q=node/16

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

Для определения типа платформы существует несколько переменных:

• UNIX – системы соответствующие стандарту POSIX (например Linux, FreeBSD или MAC OS X), включает CygWin
• WIN32 – понятно без комментариев

Зная это легко проделать нужные действия:

if (WIN32)
	set (SOURCES ${SOURCES} win_pipe.cpp)
elseif (UNIX)
	set (SOURCES ${SOURCES} posix_pipe.cpp)
else ()
	message (FATAL_ERROR "Неизвестная система")
endif ()

Обратите внимание, что команда message с ключом FATAL_ERROR выводит сообщение и прекращает выполнение работы.

Иногда этого бывает мало и необходимо точно определить тип системы или даже дистрибутив и его версию. Для этих целей можно использовать переменную CMAKE_SYSTEM:

if (${CMAKE_SYSTEM} MATCHES "Linux")
	message ("Linux")
	if (${CMAKE_SYSTEM} MATCHES "fc8")
		message ("Fedora 8")
	endif ()
elseif (${CMAKE_SYSTEM} MATCHES "FreeBSD")
	message ("FreeBSD")
elseif (${CMAKE_SYSTEM} MATCHES "Darwin")
	message ("Mac OS X")
endif ()

Полный список полезных переменных можно посмотреть в Kitware Public Wiki.

Написанием модульных тестов можно не только повысить скорость разработки за счет экономии времени на отладке, но и повысить качество. Также написание тестов позволяет критично взглянуть на интерфейсы классов и функций, что выливается в создание простых и логичных интерфейсов. Но разработка с применением тестов может не принести ощутимых плодов из-за сложности написания тестов, что выльется в слабое покрытие кода тестами. Поэтому инструмент для тестирования должен быть максимально простым, написание тестов должно происходить с приложением минимального количества усилий. Я пользовался фреймворком для написания тестов UnitTest++ – это очень хороший и удобный инструмент и если вы не используете Boost, я бы порекомендовал обратить на него пристальное внимание. Но в данной заметке речь пойдет не о нем, а о фреймворке Boost Test.

Читать заметку полностью »

В этой заметке я хочу рассмотреть тему сборки проектов использующих библиотеки Boost. Мы рассмотрим проект из исполняемого файла использующего Boost Thread и двух библиотек использующих Boost Unit Test Framework.

Первым делом необходимо установить значения переменных отвечающих за тип линковки библиотек (статическая или динамическая):

set (Boost_USE_STATIC_LIBS ON)

И использование многопоточности библиотеками:

set (Boost_USE_MULTITHREADED ON)

После этого можно выполнить уже знакомую по заметке о CMake и QT команду find_package:

find_package (Boost COMPONENTS список_нужных_модулей REQUIRED)

Дополнительно можно указать необходимую версию Boost:

find_package (Boost 1.35.0 COMPONENTS список_нужных_модулей REQUIRED)

В случае если Boost корректно установлен, результатом работы команды будет создание переменных содержащих директории с заголовочными файлами Boost и пути к необходимым библиотекам:

include_directories(${Boost_INCLUDE_DIRS})
...
target_link_libraries (${PROJECT} ${Boost_LIBRARIES})

Читать заметку полностью »

В заметке представлен способ сборки программ использующих библиотеку Qt. Рассмотрены вопросы локализации приложения и подключения ресурсов, например изображений.

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

Читать заметку полностью »

Для автоматизации сборки проектов традиционно используют системы сборки, такие как 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, как простой для изучения, понятный, мощный и кроссплатформенный инструмент, который решает сразу все три проблемы. Подробности ниже.

Читать заметку полностью »