Каков наилучший способ упорядочить код моего проекта на C и его внешние библиотеки?[закрыто]
-
09-06-2019 - |
Вопрос
Я начинаю новый проект на C, который в значительной степени основан на OSS.Это также будет на SourceForge, и я хотел бы воспользоваться этой возможностью, чтобы изучить устоявшиеся лучшие практики организации такого рода кода.Я использую такие библиотеки, как libcurl и libz, и я скомпилирую его с помощью MinGW и MSYS.
Я буду распространять копии исходных текстов всех библиотек, которые я использую в своем проекте, поэтому людям, загружающим исходный код, не придется копаться в зависимостях.Как мне следует назвать каталог, в котором я храню библиотеки?Пока что я колеблюсь между:
- lib, потому что это библиотеки.Однако слово "библиотека" имеет другое значение в мире UNIX.
- src, потому что это исходные файлы.
- 3rd party, потому что я этого не писал.
И куда мне следует скомпилировать эти библиотеки?Должен ли я просто настроить и установить их в корневой каталог системы, или я должен настроить каталог, в который должны компилироваться все библиотеки, и ссылаться оттуда?Очевидно, что это будет иметь последствия для моего Makefile.
Как мне следует поступить с этим?Существуют ли установленные соглашения, которым я должен следовать?Они где-нибудь записаны?
Решение
Во-первых, для внешних библиотек я бы использовал vendor
, но это всего лишь предпочтение.
Во-вторых, я не думаю, что это хорошая идея для установки Другое библиотеки в корневом каталоге системы, без ведома пользователей.Самое главное, потому что это будет конфликтовать с более поздними установленными версиями этих библиотек.Поэтому я думаю, что лучшим местом для этих библиотек было бы в том же каталоге, что и ваше приложение.
Вы также можете статически скомпилировать эти библиотеки в свою программу.
Другие советы
На предыдущей работе стандартом было устанавливать их в каталог с именем 3rdparty и создавать библиотеки прямо там (в 3rdparty /LIBNAME /Debug и т.д.).
Мы используем что-то с суффиксом _ext или _EXT _EXT (т.е. MyProject_EXT), чтобы указать, что оно является внешним по отношению к нашему проекту для хранения исходного кода внешних пакетов, с которыми мы связываемся.
Я согласен с Питером.Внешние библиотеки не должны быть встроены в корневой каталог системы, так как они могут вызвать конфликты.Я бы создал их в их каталоге, а затем установил их в каталог /lib (или, возможно, / extlib), который уникален для вашего приложения, и ссылался бы на них там.
Пожалуйста не надо отправляйте сторонние исходники с вашим кодом, либо в исходном коде, либо статически связанные с двоичными файлами, либо любым другим способом.Это просто будет мешать работе с другими копиями того же самого и не будет обновляться, когда библиотеке потребуется исправление.Обязательно сообщите пользователю, каковы требования (и следите за изменениями API в библиотеке!).Самокомпилирующийся пользователь позаботится о том, чтобы получить зависимости, дистрибутив позаботится о том, чтобы ваш пакет работал с той версией, которую они поставляют.