gpt4 book ai didi

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

转载 作者:塔克拉玛干 更新时间:2023-11-03 01:36:21 28 4
gpt4 key购买 nike

我正在自定义编译 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 的空间效率要高得多(还有许多其他好处)。如果您在公司无法使用 svn,也可以创建 git-svn 桥。

否则,我会为每个共享库 创建一个 svn externals。如果您有一些经常更改或在逻辑上组合在一起的东西,它可以放在一个 svn 存储库中,而其他库可能不会经常更改。

git 相对于 svn 的优势之一是 git 可以保护您免受文件损坏。我痛苦地记得有几次 svn 损坏文件(直到客户提交错误报告才注意到)。

说真的,让自己远离头痛的世界,放弃 svn,转而使用 git。

关于c++ - 构建自定义编译库的更好方法,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17792774/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com