指定链接库的 makefile 位置
我最近在我正在进行的一个项目中偶然发现了这一点。在包 A 中，有一个必需的配置选项 --package-B-makefile-location，A 的 makefile 从中借用变量值。
这是一种有优点的常见设计模式吗？在我看来，B 的包源代码与编译 A 的二进制文件一样重要。是否有我不想篡改它的原因？
谢谢，
安德鲁
I recently stumbled upon this in a project I'm working on. In package A, there is a required configuration option --package-B-makefile-location from which A's makefile borrows variable values.
Is this a common design pattern which has merit? It seems to me that B's package source is as important as its binary for compiling A. Might there be reasons I wouldn't want to tamper with it?
Thanks,
Andrew
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一个软件包需要预安装其他软件包的情况绝非闻所未闻，您必须指定这些位置。
例如，构建 GCC (4.5.2) 时，如果默认情况下找不到 GMP、MPFR 和 MPC 库，则需要指定它们的位置。
可扩展的复杂系统 - Perl、Apache、Tcl/Tk、PHP - 以各种方式向用户提供配置数据（Perl 的 Config.pm、Apache 的 apxs 等），但配置数据对于依赖模块至关重要。
我怀疑您的包 A 需要一些与包 B 相关的配置数据，但没有一个成熟的系统来提供它。作为解决方法，包 A 需要查看 makefile 中封装的配置数据。
需要 makefile 的情况并不常见；需要有关其他软件包的一些信息并不罕见。
It is far from unheard of for one package to need other packages pre-installed, and you have to specify those locations.
For example, building GCC (4.5.2), you need to specify the locations of the GMP, MPFR and MPC libraries if they won't be found by default.
Complex systems which are extensible - Perl, Apache, Tcl/Tk, PHP - provide configuration data to their users in various ways (Config.pm for Perl, apxs for Apache, etc), but that configuration data is crucial to dependent modules.
My suspicion is that your Package A needs some of the configuration data related to Package B, but there isn't a fully-fledged system for providing it. As a workaround, Package A needs to see the configuration data encapsulated in the makefile.
It is not common to need the makefile; it is not uncommon to need some information about other packages.
就其本身而言，这是一种常见且有用的设计模式，但它也可能像其他模式一样被滥用。
我不确定我是否理解你问题的第二部分，但如果 makefile 设计良好，那么你对 B 的 makefile 所做的任何更改不会破坏 B，也不会破坏 A。
It's a common and useful design pattern as far as it goes, but it can be abused like any other.
I'm not sure I understand the second part of your question, but if the makefiles are well designed then any change you make to B's makefiles which doesn't break B won't break A either.