Лучший способ структурирования пользовательских подчиненных библиотек

Я настраиваю libcurl, libssl и другую библиотеку. Я не хочу заменять системную библиотеку, потому что, если я изменю ее систему, она создаст конфликт lib, и мне нужно будет скомпилировать все остальные компоненты в зависимости от этих библиотек.Лучший способ структурирования пользовательских подчиненных библиотек

Так что я начал использовать 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 в каждом приложении?

источник

2013-07-22 Vivek Goel

Это было слишком долго, так как я играл с подрывной, чтобы дать официальный ответ , но не можете ли вы поместить свои собственные библиотеки в отдельный репозиторий subversion (или каталог верхнего уровня? Я забыл свои условия) и добавить этот репозиторий в качестве внешней зависимости subversion для каждого проекта? Это даст вам место для редактирования и хранения ваших файлов и позволит нескольким проектам захватить результаты. –

@ vivek-goel - это второе дерево для другой вещи - или это просто более поздняя версия первого дерева? –

@IwanAucamp Это более поздняя версия первого дерева. –

Как человек, который много лет использовал и git и svn, я бы серьезно подумал о переходе на git и использовании git-подмодулей. Git чрезвычайно эффективен в пространстве (среди многих, многих других преимуществ). Есть также git-svn мосты, которые вы можете сделать, если вы застряли с помощью svn в своей компании.

В противном случае я сделал бы svn externals для каждой группы разделяемых библиотек. Если у вас есть что-то, что часто меняется или логически сгруппировано вместе, оно может идти в одном svn-репо, а другие библиотеки могут не изменяться очень часто.

Одним из преимуществ git over svn является то, что git защищает вас от повреждения файлов. Я могу мучительно помнить несколько случаев svn-развращающих файлов (то, что не было замечено, пока клиент не отправил отчет об ошибке).

Серьезно, спасите себе мир головных болей, канаву svn в пользу git.

источник

2013-07-24 06:00:48 Homer6

У меня был совершенно другой подход, когда я работал с C++.

Я не рассматриваю libs как часть исходного кода. Я только хочу, чтобы «зависимость» существовала с моим источником. (В любом случае, не обязательно иметь «контроль версий» для двоичного файла lib)

У меня есть отдельный каталог для хранения всех библиотек организованно, что-то вроде libname/version/arch.

В скрипте сборки я имею в виду что-то вроде $ LIB_DIR/libname/version/arch/lib-ver.so.

Вы можете иметь различный способ хранения/распространять каталог Lib, либо поместить его в объеме сети, положить, что в SVN и т.д.

источник

2013-07-24 06:20:06

@Adiran Shum Я поддерживаю svn для легкого развертывания. –

Лучший способ структурирования пользовательских подчиненных библиотек

ответ

Смежные вопросы