Как хранить зависимости библиотеки C в управлении версиями?

Question

Исходя из опыта Rails, я привык указывать зависимости моего приложения в Gemfile, который проверяется в моем git-репо. Когда мое приложение извлекается, пользователю просто нужно запустить bundle install, и у него есть все необходимые зависимости.

В этом ответе сообщество, похоже, согласилось с тем, что библиотеки C не должны попадать в систему контроля версий. Это имеет смысл (в конце концов, сами Gems не зарегистрированы в Rails), но все равно создает проблему. Если я напишу некоторый код и включу новую зависимость от созданной пользователем библиотеки, как я могу выразить эту зависимость в контроле исходного кода?

Answer 1

Очевидно, что вещи в мире C немного отличаются, потому что вам не нужен источник во время выполнения.Обычный способ работы в системах GNU / Linux (и многих других * ix) заключается в том, что некоторые этапы настройки выполняются с использованием сценария или программы настройки.Наиболее распространенным из них является знаменитый скрипт configure, сгенерированный GNU autoconf.Автоинструменты генерируют много файлов кеша и копируют множество вспомогательных сценариев в дерево исходных текстов, поэтому не забудьте установить .gitignore, или вы сойдете с ума.

Очень многие библиотеки устанавливают управляющие файлы для pkg-config в $prefix/lib/pkgconfig или $prefix/share/pkgconfig.Они считываются инструментом pkg-config для проверки существования библиотек и получения правильных флагов компилятора и компоновщика для этой библиотеки.Они представляют собой простой текст, поэтому посмотрите в /usr/lib/pkgconfig, чтобы получить представление о том, как они выглядят.

В autoconf файл configure.ac компилируется в configure путем вызова макросапроцессор m4 (через оболочку с именем autoconf).Проверить библиотеку, которая работает с pkg-config, очень просто.Вы добавляете что-то вроде следующего к configure.ac

# Checks for libraries.
PKG_CHECK_MODULES([GLib], [glib-2.0])

. Это проверит, что pkg-config установлен, а затем использует его для проверки пакета glib-2.0, распечатывая сообщение Checking for GLib... по пути.,Он также установит переменные оболочки GLib_CFLAGS и GLib_LIBS и организует их замену на любые файлы, созданные с помощью AC_CONFIG_FILES (например, Makefile из Makefile.in).Если он не найдет glib, configure завершится с ошибкой.Посмотрите на /usr/share/aclocal/pkg.m4, чтобы найти определение PKG_CHECK_MODULES, которое поддерживает несколько других опций.Документация находится на справочной странице pkg-config(1).

Если ваша зависимая библиотека не поддерживает pkg-config, иногда поставщик библиотеки предоставляет макрос autoconf.Старые версии SDL, например, предоставляли AM_PATH_SDL, но в новых версиях просто используется pkg-config.

Если от поставщика нет поддержки, иногда в стороннем архиве autoconf есть сторонняя поддержка .Архив autoconf доступен в виде пакета в Debian GNU / Linux и MacPorts (и, возможно, во многих других системах), что означает, что любые необходимые определения могут использоваться без копирования .m4 файлов вручную.

Если нетиз вышеприведенного верно, затем проверьте заголовок, используя что-то вроде AC_CHECK_HEADER и проверьте библиотеку, используя что-то вроде AC_CHECK_LIB.

Answer 2

Сообщество, похоже, согласилось с тем, что библиотеки C не должны проверяться в системе контроля версий.

Зависит от используемой вами библиотеки. Например, когда я использую Sqlite, я проверяю файлы sqlite в моем контроле версий и собираю его из моих исходных файлов. Это легко, так как sqlite поставляется с одним исходным файлом и заголовком. Это не будет практично, если в библиотеке будет больше файлов.

но это все равно создает проблему. Если я напишу некоторый код и включу новую зависимость от библиотеки, созданной пользователем, как я могу выразить эту зависимость в контроле исходного кода?

В Linux это обрабатывается с помощью автоинструментов. Используя это, вы можете указать пакеты для использования, и configure попытается найти его при сборке. Если вы ищете кроссплатформенное решение, CMake - лучший инструмент. Эти инструменты могут найти пакеты, установленные в стандартных местоположениях (/usr/lib & /usr/include), а также предоставляют способ настройки патча поиска.