本文介绍了关于如何部署 C++ 代码以在任何地方工作的提示的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我不是在谈论制作可移植的代码.这更多是一个分配问题.我有一个中型项目.它对公共库(例如 openssl、zlib 等)有几个依赖项.它在我的机器上编译得很好,现在是时候将它提供给全世界了.

I'm not talking about making portable code. This is more a question of distribution. I have a medium-sized project. It has several dependencies on common libraries (eg openssl, zlib, etc). It compiles fine on my machine and now it's time to give it to the world.

本质上以最好的方式构建工程.我想为 Windows、Linux、MacOSX 等制作安装程序.我想制作一个可下载的 tar 球,使代码可以与 ./configuremake 一起使用(可能通过 autoconf).有一个可以构建安装程序的 make 选项将是锦上添花.甚至可以交叉编译,以便可以在 Linux 中构建 Windows 安装程序.

Essentially build engineering at its finest. I want to make installers for Windows, Linux, MacOSX, etc. I want to make a downloadable tar ball that will make the code work with a ./configure and a make (probably via autoconf). It would be icing on the cake to have a make option that would build the installers..maybe even cross-compile so a Windows installer could be built in Linux.

最好的策略是什么?我可以在哪里花费最多的时间?主要焦点应该是 autoconf 还是其他工具可以提供帮助?

What is the best strategy? Where can I expect to spend the most time? Should the prime focus be autoconf or are there other tools that can help?

推荐答案

我推荐 CMake.优点:

  • 使用静态库、动态库、可执行文件及其依赖项构建简单和复杂的项目非常容易.
  • 它与平台无关,可为大多数编译器和 IDE 生成 makefile 和/或 ide 项目文件.
  • 它抽象了windows和unix之间的差异,例如libShared.so"和Shared.dll"被称为Shared"(cmake处理每个平台的名称差异),如果Shared是你项目的一部分整理依赖项,如果不是,则假定它在链接器路径中.
  • 它会调查用户系统是否需要编译器和 3rd 方库,然后您可以在 3rd 方库不可用或显示错误消息时选择删除组件(它随附宏以查找最常见的 3rd 方库).
  • 它可以从命令行或使用简单的 gui 运行,使用户能够更改上面发现的任何参数(例如编译器或第 3 方库的版本).
  • 它支持用于自动执行常见步骤的宏.
  • 有一个叫做 CPack 的组件可以让你创建一个安装程序,我认为这只是一个 make install 命令行的东西(我没有用过).
  • CTest 组件与其他单元测试库(如 boost test 或 google test)集成.
  • It is very easy to use for building simple and complex projects with static libraries, dynamic libraries, executables and their dependencies.
  • It is platform independent and generates makefiles and/or ide project files for most compilers and IDEs.
  • It abstracts the differences between windows and unix, eg "libShared.so" and "Shared.dll" are referred to as "Shared" (cmake handles the name differences for each platform), if Shared is part of your project it sorts out the dependency if not it assumes that it is in the linker path.
  • It investigates the users system for compiler and 3rd party libraries that are required, you can then optionally remove components when 3rd party libraries are not available or display an error message (It ships with macros to find most common 3rd party libraries).
  • It can be run from the command line or with a simple gui that enables the user to change any of the parameters that were discovered above (eg compiler or version of 3rd party library).
  • It supports macros for automating common steps.
  • There is a component called CPack that enables you to create an installer, I think this is just a make install command line thing (I have not used it).
  • The CTest component integrates with other unit testing libraries like boost test or google test.

我现在使用 CMake 处理所有事情,甚至是使用 Visual Studio 的简单测试项目.

I use CMake for everything now, even simple test projects with visual studio.

我从未使用过 autotools,但很多其他用户评论说 cmake 更易于使用.出于这个原因,KDE 项目从 autotools 转移到了 cmake.

I have never used autotools but a lot of other users have commented that cmake is easier to use. The KDE project moved to cmake from autotools for this reason.

这篇关于关于如何部署 C++ 代码以在任何地方工作的提示的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-26 14:11