Boost bjam 与 GNU make

发布于 2024-07-20 05:50:30 字数 111 浏览 8 评论 0原文

我是 Boost C++ 库的新手。 我想知道 Boost bjam 相对于 GNU make 是否有任何优势? 如果我使用 make 来利用 Boost.Python 库构建 C++ 代码,有什么缺点?

I am a newbie to Boost C++ libraries. I was wondering if there are any advantages of Boost bjam over GNU make? And what are the cons if I use make for building C++ code utilizing Boost.Python libraries?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

℡寂寞咖啡 2024-07-27 05:50:30

到目前为止,对于构建 boost 本身,bjam 是最佳选择。 只需按照自述文件构建命令行即可。 您可能(应该)只需在每个增强版本中执行一次。

但是,没有必要将您自己使用 boost 的项目与 boost 的构建系统联系起来。

使用 gmake 构建使用 Boost.Python 的 C++ 代码没有什么特别的缺点,优点是有大量使用 gmake 的示例。

For building boost itself, bjam is the way to go, by far. Just follow the readme and construct the command line. You may (should) only have to do it once per boost release.

But, there's no need whatever to tie your own project that uses boost to boost's build-system.

There are no particular cons to using gmake to build C++ code that uses Boost.Python, and the pro is that there are plenty of examples of using gmake around.

北城半夏 2024-07-27 05:50:30

如果您打算使用其他 Boost 库,那么使用 bjam 可能是有意义的,但是,从简单的角度来看,对于复杂的项目来说,make 的使用非常复杂,这就是开发 ant 的原因。

Bjam 扩展了其他最初尝试取代 make 的项目。

但是,缺点是,每个 UNIX 操作系统上都可以找到 make,而 bjam 则不然,但是,如果您必须在项目中使用 Boost 库,那么您可以确保包含它。

对于你的项目,我认为 bjam 可能是最好的选择,但如果你正在编写一个其他人需要使用 ANSI C++ 编译的可移植项目,那么我建议也支持 GNU Make。

If you are going to use other Boost libraries then using bjam may make sense, but, from a simple point of view, make is very complicated to work with, for a complex project, which is why ant, for example was developed.

Bjam extends other projects that started with trying to replace make.

But, on the downside, make is found on every unix OS, bjam isn't, but, if you have to use Boost libraries for your project then you can make certain it is included.

For your project I think bjam may be the best option, but if you were writing a portable project that others would need to compile, using ANSI C++, then I would suggest also supporting GNU Make.

阳光的暖冬 2024-07-27 05:50:30

我使用 Make 和 BJam 构建了团队共享构建框架。
我的最终意见是,一旦我了解了基本设置,bjam 实现就更容易维护。 团队成员一开始可能会抗拒,但一旦他们使用它并发现它比 Make 简单得多(我的观点),他们就会被说服。 有些人会继续抵制。 您可以设置双构建系统,但这是额外的工作。

当我被迫使用 Make 时,我会使用中心规则集创建非递归 makefile 解决方案。 BJam 内置了这一切。

I've built team shared build frameworks using Make and BJam.
My final opinion was that the bjam implementation was easier to maintain, once I learned the basic setup. Team members may be resistant at first, but once they use it and see how it is far simpler than Make (my opinion), they are won over. Some will continue to resist. You can set up dual build systems, but that is extra effort.

When I am forced to use Make, I create non-recursive makefile solutions with central rule sets. BJam has all this built in.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文