Лучший способ структурировать пользовательские библиотеки
Я настраиваю сборку libcurl, libssl и некоторых других библиотек. Я не хочу заменять системную библиотеку, потому что, если я изменю ее системно, это приведет к конфликту библиотек, и мне нужно скомпилировать все остальные компоненты в зависимости от этих библиотек.
Поэтому я начал использовать RPATH и начал структурировать так:
|-- bin
| |-- app.out
|-- lib
| |-- libboost_program_options.so -> libboost_program_options.so.1.49.0
| |-- libboost_program_options.so.1.49.0
| |-- libboost_system.so -> libboost_system.so.1.49.0
| |-- libboost_system.so.1.49.0
| |-- libboost_thread.so -> libboost_thread.so.1.49.0
| |-- libboost_thread.so.1.49.0
| |-- libcares.so -> libcares.so.2.0.0
| |-- libcares.so.2 -> libcares.so.2.0.0
| `-- pkgconfig
`-- sbin
`-- nginx
Этот подход сработал. Теперь проблема в том, что мы начали использовать PHP и узел, который требует одинаковую версию приложения.
|-- bin
| |-- a.out
|-- lib
| |-- libboost_program_options.so -> libboost_program_options.so.1.49.0
| |-- libboost_program_options.so.1.49.0
| |-- libboost_system.so -> libboost_system.so.1.49.0
| |-- libboost_system.so.1.49.0
| |-- libboost_thread.so -> libboost_thread.so.1.49.0
| |-- libboost_thread.so.1.49.0
| |-- libcares.so -> libcares.so.2.0.0
| |-- libcares.so.2 -> libcares.so.2.0.0
| `-- pkgconfig
|-- php_ext
| `-- sqlite3.so
|-- node
| `-- node_modules
| |-- bin
| | |-- node
`-- sbin
`-- nginx
Теперь это SVN репо становится все больше и больше с каждым выпуском. Есть ли лучший способ структурировать это? без дублирования папки lib в каждом приложении?
Решение
Как человек, который много лет использовал и git, и svn, я бы серьезно подумал о переходе на git и использовании подмодулей git. Git намного более компактен (среди множества других преимуществ). Существуют также мосты git-svn, которые вы можете создать, если у вас возникли проблемы с использованием svn в вашей компании.
В противном случае я бы сделал svn externals для каждого группа общих библиотек. Если у вас есть что-то, что часто меняется или логически сгруппировано, это может быть сделано в одном репозитории svn, в то время как другие библиотеки могут меняться не очень часто.
Одним из преимуществ git перед svn является то, что git защищает вас от повреждения файлов. Я с трудом могу вспомнить несколько случаев повреждения файлов SVN (что не было замечено, пока клиент не отправил отчет об ошибке).
Серьезно, избавь себя от мира головных болей, брось svn в пользу git.
Другие решения
Я использовал совершенно другой подход, когда работал с C ++.
Я не отношусь к библиотекам как к части исходного кода. Я только хочу, чтобы «зависимость» существовала с моим источником. (В любом случае нецелесообразно иметь «контроль версий» для двоичного файла lib)
У меня есть отдельный каталог для упорядоченного хранения всех библиотек, что-то вроде libname / version / arch.
В скрипте сборки я имею в виду что-то вроде $ LIB_DIR / libname / version / arch / lib-ver.so.
Вы можете по-разному хранить / распространять каталог Lib, либо поместить его в сетевой том, поместить его в SVN и т. Д.
detector