Ох уж эти зависимости
Это "удивительная" история связана с тем, что возникла необходимость использования различных библиотек, т.к. периодически возникает необходимость использования логирования, модульных тестов и т.п. в проектах, компилируемых и запускаемых под Linux. Для Windows и ряда дистрибутивов Linux ситуация довольно простая, т.к.
1) Для Windows в Visual Studio проектах можно использовать нативные nuget-пакеты.
2) Для дистрибутивов Linux, в которых есть менеджер пакетов (.deb или .rpm) многие библиотеки и их зависимости могут быть установлены таким способом.
Но есть большое НО:
1. Не все библиотеки могут быть в менеджере пакетов nuget или в менеджере пакетов Linux (хотя речь, конечно, идет о проектах под Linux).
2. Дистрибутив может быть довольно старым, и в менеджере пакетов нет свежих библиотек.
3. Сам дистрибутив не имеет менеджера пакетов (Arch, Gentoo, различные маленькие и легковесные дистрибутивы).
Как же быть? Примеры работы с различными библиотеками
Самый подходящий вариант - собирать библиотеки вместе с проектом, написать Makefile или bash-скрипт для выполнения этой работы. Как правило проекты библиотек располагаются в директории contrib.
Log4Cpp - неплохая библиотека для логирования сообщений в проектах, имеет богатые настройки и кучу различных аппендеров (менеджеров разных видов записи, например в раскрашенном виде в консоль, в циклически перезаписываемый файл и т.п.). К сожалению библиотека (ее актуальная версия) собраны с использованием autotools, что само по себе уже капкан, т.к. проекты automake не переносимы в пределах разных версий тулсета (во всяком случае мне не встречались такие проекты). liblog4cpp.so отсутствует в моей системе (OpenSuse 42.1), поэтому я использую следующий скрипт (после configure) для сборки:
#! /bin/bash
# Check that configure was not executed
if [ ! -f libtool ]; then
./autogen.sh
./configure --with-pthreads
fi
# Check that make was not executed
#if [ ! -d ./srx/.libs ]; then
#make
#fi
make clean
make
Gtest - библиотека для написания модульных тестов. Собирается куда как проще, т.к. создана без помощи этих ужасных autotools, ее я собираю следующим способом:
#! /bin/bash
GTEST_DIR=.
#../../contrib/gtests
#=.
rm -rf ${GTEST_DIR}/libgtest*
rm -rf ${GTEST_DIR}/*.o
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} -pthread -c ${GTEST_DIR}/src/gtest-all.cc
ar -rv ${GTEST_DIR}/libgtest.a gtest-all.o
EasyCmdLineReader - легковесная библиотека для работы с аргументами командной строки. Эта библиотека собирается моим кастомным makefile-ом https://github.com/IzyaSoft/EasyCli/blob/master/Makefile , шаблон для сборки произвольной либы может быть взят отсюда: https://github.com/IzyaSoft/EasyMakeSharedLib . Но данная библиотека легко собирается через просто make (который можно запустить также из шелл скрипта).
Итог
Opensource предоставляет шикарные возможности для контроля используемого в проектах кода, однако он и создает ряд проблем для сборки. Вышеупомянутый способ использования библиотек в проектах, когда нет возможности использования пакетов имеет и ряд недостатков: прежде всего хранение в репозитории дополнительных файлов исходного кода используемых библиотек, сложности в сборки (все тот же autotolls, а также зависимости, которые могут не поддерживаться конкретным Linux дистрибутивом).
Это "удивительная" история связана с тем, что возникла необходимость использования различных библиотек, т.к. периодически возникает необходимость использования логирования, модульных тестов и т.п. в проектах, компилируемых и запускаемых под Linux. Для Windows и ряда дистрибутивов Linux ситуация довольно простая, т.к.
1) Для Windows в Visual Studio проектах можно использовать нативные nuget-пакеты.
2) Для дистрибутивов Linux, в которых есть менеджер пакетов (.deb или .rpm) многие библиотеки и их зависимости могут быть установлены таким способом.
Но есть большое НО:
1. Не все библиотеки могут быть в менеджере пакетов nuget или в менеджере пакетов Linux (хотя речь, конечно, идет о проектах под Linux).
2. Дистрибутив может быть довольно старым, и в менеджере пакетов нет свежих библиотек.
3. Сам дистрибутив не имеет менеджера пакетов (Arch, Gentoo, различные маленькие и легковесные дистрибутивы).
Как же быть? Примеры работы с различными библиотеками
Самый подходящий вариант - собирать библиотеки вместе с проектом, написать Makefile или bash-скрипт для выполнения этой работы. Как правило проекты библиотек располагаются в директории contrib.
Log4Cpp - неплохая библиотека для логирования сообщений в проектах, имеет богатые настройки и кучу различных аппендеров (менеджеров разных видов записи, например в раскрашенном виде в консоль, в циклически перезаписываемый файл и т.п.). К сожалению библиотека (ее актуальная версия) собраны с использованием autotools, что само по себе уже капкан, т.к. проекты automake не переносимы в пределах разных версий тулсета (во всяком случае мне не встречались такие проекты). liblog4cpp.so отсутствует в моей системе (OpenSuse 42.1), поэтому я использую следующий скрипт (после configure) для сборки:
#! /bin/bash
# Check that configure was not executed
if [ ! -f libtool ]; then
./autogen.sh
./configure --with-pthreads
fi
# Check that make was not executed
#if [ ! -d ./srx/.libs ]; then
#make
#fi
make clean
make
Gtest - библиотека для написания модульных тестов. Собирается куда как проще, т.к. создана без помощи этих ужасных autotools, ее я собираю следующим способом:
#! /bin/bash
GTEST_DIR=.
#../../contrib/gtests
#=.
rm -rf ${GTEST_DIR}/libgtest*
rm -rf ${GTEST_DIR}/*.o
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} -pthread -c ${GTEST_DIR}/src/gtest-all.cc
ar -rv ${GTEST_DIR}/libgtest.a gtest-all.o
EasyCmdLineReader - легковесная библиотека для работы с аргументами командной строки. Эта библиотека собирается моим кастомным makefile-ом https://github.com/IzyaSoft/EasyCli/blob/master/Makefile , шаблон для сборки произвольной либы может быть взят отсюда: https://github.com/IzyaSoft/EasyMakeSharedLib . Но данная библиотека легко собирается через просто make (который можно запустить также из шелл скрипта).
Итог
Opensource предоставляет шикарные возможности для контроля используемого в проектах кода, однако он и создает ряд проблем для сборки. Вышеупомянутый способ использования библиотек в проектах, когда нет возможности использования пакетов имеет и ряд недостатков: прежде всего хранение в репозитории дополнительных файлов исходного кода используемых библиотек, сложности в сборки (все тот же autotolls, а также зависимости, которые могут не поддерживаться конкретным Linux дистрибутивом).
Комментариев нет:
Отправить комментарий