构建自定义编译库的更好方法

问题描述 投票:1回答:2

我是自定义编译libcurl,libssl和其他一些库。我不想替换系统库,因为如果我在系统方面改变它,它将创建lib冲突,我需要根据这些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 repo在每次发布后都变得越来越大。有没有更好的方法来构建它?没有在每个应用程序中复制lib文件夹?

c++ linux directory-structure
2个回答
0
投票

作为多年来广泛使用git和svn的人,我会认真考虑转向git并使用git子模块。 Git的空间效率更高(许多其他好处)。如果您在公司使用svn,也可以使用git-svn桥。

如果做不到这一点,我会为每组共享库创建一个svn外部。如果您经常更改某些内容或在逻辑上将其组合在一起,则可以使用一个svn repo,而其他库可能不会经常更改。

git over svn的一个优点是git可以保护你免受文件损坏。我可以痛苦地记住几次svn损坏文件(在客户端提交错误报告之前没有注意到的事情)。

说真的,保护自己一个头痛的世界,放弃svn支持git。


0
投票

当我使用C ++时,我采取了完全不同的方法。

我不把libs视为源代码的一部分。我只希望“依赖”与我的源存在。 (无论如何都要对lib二进制文件进行“版本控制”)

我有一个单独的目录来以有组织的方式存储所有的lib,比如libname / version / arch。

在构建脚本中,我指的是$ LIB_DIR / libname / version / arch / lib-ver.so。

您可以使用不同的方式来存储/分发Lib目录,将其放在网络卷中,将其放在SVN等中。

© www.soinside.com 2019 - 2024. All rights reserved.