Где я могу разместить сторонние библиотеки для настройки среды разработки C++ Linux?

Я не новичок в C++, хотя я новичок в Linux. Я использую CMake для предварительной компиляции кроссплатформенного игрового движка с некоторыми сторонними компонентами, но у меня много сомнений по поводу использования библиотек. У меня вопрос как работать со сторонними библиотеками и куда их ставить. Apt устанавливает libs на официальном месте (/usr/local,/usr/lib/..), но я разрабатываю в Windows, используя локальные библиотеки, которые находятся в папке в моем каталоге проекта.

Кроме того, мне нужен хороший учебник, чтобы знать правила работы библиотек. Например: при попытке скомпилировать мой проект luabind запрашивает liblua.s0.1, но AFAIK нет способа сгенерировать эту библиотеку с исходным кодом, предоставленным Lua (по крайней мере, с помощью make, make install).

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

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

Ответ 1

Где поставить библиотеки

Лучшее решение - использовать систему дистрибутива Linux (apt-get, yum или аналогичную) для установки библиотек из пакетов, предоставляемых дистрибутивом, где это возможно.

Если в дистрибутивных библиотеках недостаточно свежая версия, или если вам нужны нестандартные параметры сборки, или если вам нужна библиотека, которую ваш дистрибутив не предоставляет, вы можете собрать и установить ее самостоятельно. У вас есть два основных варианта расположения библиотеки:

/usr/local (библиотеки в /usr/local/lib, заголовки в /usr/local/include). Это устанавливает библиотеки в масштабе всей системы и, вероятно, является самым простым решением, поскольку тогда вы сможете использовать их без каких-либо дополнительных действий. НЕ устанавливайте библиотеки непосредственно в /usr, так как это повлияет на вашу систему упаковки дистрибутивов.
В каталоге вашего проекта, как вы сделали в Windows. Это дает преимущества, заключающиеся в том, что вам не требуется доступ с правами root и внесение изменений в масштабе всей системы, но вам нужно будет обновить пути проекта, включая пути и пути к библиотекам, и вам нужно будет поместить любые файлы общей библиотеки в такое место, где их может найти динамический компоновщик используя LD_LIBRARY_PATH или ld.so.conf - см. ссылку для более подробной информации).

Как работают библиотеки

См. Превосходное руководство по программированию Дэвида А. Уилера. Я бы рекомендовал прочитать это, а затем опубликовать любые конкретные вопросы в качестве новых тем.

Как распространять вашу программу

Традиционно программы Unix/Linux не включают в себя копии своих зависимостей. Это вместо того, чтобы до конечного пользователя или разработчика устанавливать эти зависимости самостоятельно. Это может потребовать "большого README", как вы сказали, но у него есть несколько преимуществ:

Библиотеки разработки могут устанавливаться, управляться и обновляться через менеджер пакетов distro, вместо того чтобы каждая исходная копия имела свой собственный набор библиотек для отслеживания.
В системе имеется только одна копия любой данной библиотеки, поэтому существует только одно место, которое нуждается в обновлении, если, например, обнаружен брешь в безопасности. (Например, рассмотрим хаос, возникший, когда zlib, очень широко используемая библиотека сжатия, обнаружила недостаток безопасности, поэтому каждое приложение, включающее уязвимую версию, необходимо было обновить.)
Если ваша программа достаточно популярна (и с открытым исходным кодом или, по крайней мере, свободно доступна), тогда разработчики пакетов для различных дистрибутивов Linux могут захотеть упаковать ее и включить в свой дистрибутив. Разработчики пакетов действительно не любят связанные библиотеки. Смотрите, например, страницу Fedora по теме.

Если вы распространяете свою программу среди конечных пользователей, возможно, вы захотите предложить пакет (.dpkg или .rpm), который они могли бы просто загрузить и установить без использования исходного кода. В идеале, с точки зрения конечного пользователя, пакет должен быть добавлен в репозитории дистрибутива (если он с открытым исходным кодом или, по крайней мере, свободно доступен), чтобы пользователи могли загрузить его с помощью своих менеджеров пакетов (apt-get или yum). Это может все усложниться из-за большого количества дистрибутивов Linux, но Debian/Ubuntu-совместимый .dpkg и Red Hat/CentOS/Fedora-совместимый .rpm должны охватывать значительный процент конечных пользователей. Сборка пакетов не слишком сложна, и в Интернете есть хорошие советы.

Ответ 2

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

ваши проекты:

d:/projects/projectA
d:/projects/projectB

сторонний материал:

d:/api/lib/lua.lib
d:/api/include/lua/....

(вы можете даже использовать символические ссылки aka "переходы каталога", если у вас есть другая версия)

и соответствующий файл cmake:

include_directories( d:/api/include )
link_directories( d:/api/lib )

Ответ 3

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

При создании проекта вашему компилятору необходимо будет найти файлы заголовков библиотек. Заголовки должны быть включены в путь.
После компиляции компоновщик будет искать двоичные файлы библиотеки (files.so или что-то в этом роде). Они должны находиться в пути к библиотеке.

Это основы.

Если у вас есть определенные библиотеки, вы можете добавить их в свои собственные специфичные для проекта директории lib/ и include/ и добавить их в путь include и путь к библиотеке соответственно.

Добавление этих каналов на эти пути может быть сделано разными способами, в зависимости от того, как вы строите проект. Я уверен, что во всем этом есть что-то, что называется LD_PATH... Но я действительно не знаю особенностей, связанных с CMake.

Небольшой поиск в Google может помочь вам сделать это с помощью CMake.

Надеюсь, что поможет,
JRH

Ответ 4

Если вы устанавливаете библиотеки с менеджером пакетов, они, вероятно, все окажутся в нужном месте. Если нет, вы можете заставить компилятор выполнить поиск, предоставив дополнительный путь поиска, используя флаг -L <path>. Вы должны передать этот дополнительный флаг CMake.

Кстати, -I <path> можно использовать для добавления дополнительного каталога для поиска включенных файлов.