1

我正在自定义编译 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 repo 在每次发布后都变得越来越大。有没有更好的方法来构建这个？没有在每个应用程序中复制 lib 文件夹？

4

2 回答 2

0

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

我不将库视为源代码的一部分。我只希望“依赖”与我的源一起存在。（无论如何，对 lib 二进制文件进行“版本控制”是不合适的）

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

在构建脚本中，我指的是 $LIB_DIR/libname/version/arch/lib-ver.so 之类的东西。

您可以有不同的方式来存储/分发 Lib 目录，或者将其放入网络卷中，将其放入 SVN 等。

于 2013-07-24T06:20:06.347 回答
0

作为多年来广泛使用 git 和 svn 的人，我会认真考虑迁移到 git 并使用 git 子模块。Git 的空间效率大大提高（在许多其他好处中）。如果您在公司无法使用 svn，也可以使用 git-svn 桥接器。

如果做不到这一点，我会为每组共享库制作一个 svn externals。如果您有一些经常更改或逻辑分组在一起的东西，它可以放在一个 svn 存储库中，而其他库可能不会经常更改。

与 svn 相比，git 的优势之一是 git 可以保护您免受文件损坏。我可以痛苦地记得几次 svn 损坏文件（直到客户提交错误报告才注意到的事情）。

说真的，为自己省去一个令人头疼的世界，抛弃 svn 转而使用 git。

于 2013-07-24T06:00:48.497 回答