Lou*_*lin 22 compiling programming
我有时从源代码编译应用程序，我一直在使用：
./configure
make
sudo make install
但是最近，我遇到了./autogen.sh它为我生成配置和制作脚本并执行它们。
还有哪些其他方法可以简化 C/C++/C#(mono) 编译？make 好像有点老了。有没有新的工具？如果有选择，我应该使用哪一个？
mig*_*aza 44
Autoconf 和 Automake 旨在解决 Unix 的一个进化问题。
随着 Unix 向不同方向发展，想要可移植代码的开发人员倾向于编写这样的代码：
#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif
由于 Unix 被分成不同的实现（BSD、SystemV、许多供应商分支，以及后来的 Linux 和其他类 Unix 系统），对于想要编写可移植代码以编写不依赖于特定操作系统品牌的代码的开发人员来说变得很重要，但在操作系统公开的功能上。这很重要，因为 Unix 版本会引入一个新功能，例如“发送”系统调用，后来其他操作系统会采用它。与检查品牌和版本的代码不同，开发人员开始按功能进行探索，因此代码变为：
#if HAVE_SEND
Use Send here
#else
Use something else
#endif
大多数 90 年代编译源代码的 README 文件都指向开发人员编辑 config.h 文件并注释掉系统上可用的适当功能，或者为每个经过测试的操作系统配置提供标准的 config.h 文件。
这个过程既麻烦又容易出错，这就是 Autoconf 的由来。您应该将 Autoconf 视为一种由带有特殊宏的 shell 命令组成的语言，它能够用探测操作系统功能的工具替换 config.h 的人工编辑过程。
您通常会在文件 configure.ac 中编写探测代码，然后运行 autoconf 命令，该命令会将这个文件编译为您所看到的可执行配置命令。
因此，当您运行时，./configure && make您正在探索系统上可用的功能，然后使用检测到的配置构建可执行文件。
当开源项目开始使用源代码控制系统时，检查 configure.ac 文件是有意义的，而不是检查编译（配置）的结果。autogen.sh 只是一个小脚本，它为您调用带有正确命令参数的 autoconf 编译器。
——
Automake 也是从社区现有的实践中发展起来的。GNU 项目为 Makefile 标准化了一组常规目标：
make all 将构建项目make clean 将从项目中删除所有已编译的文件make install 会安装软件make dist并且make distcheck会准备分发的源代码并验证结果是一个完整的源代码包构建兼容的 makefile 变得繁重，因为有很多样板文件一遍又一遍地重复。所以 Automake 是一个新的编译器，它与 autoconf 集成并将“源”Makefile（名为 Makefile.am）处理成 Makefile，然后可以将其提供给 Autoconf。
automake/autoconf 工具链实际上使用了许多其他辅助工具，并且它们由其他组件增强以用于其他特定任务。随着按顺序运行这些命令的复杂性增加，对准备运行脚本的需求诞生了，这就是 autogen.sh 的来源。
据我所知，Gnome 是一个引入了使用这个辅助脚本 autogen.sh 的项目
Eli*_*rey 15
该领域有两个“大玩家”；Cmake 和 GNU Autotools。
GNU Autotools 是 GNU 做事的方式，并且相当专注于 *nix。它是一种元构建系统，提供一组工具来生成特定的配置并为您尝试做的事情制作文件。这有助于您在代码中进行更多更改，而无需直接操作您的构建系统，并帮助其他人以您没有设计的方式构建您的代码 - 在 *nix 下。
Cmake 是跨平台的做事方式。Cmake 团队以许多不同的方式构建软件，包括 GCC、Visual Studio、XCode、Windows、OSX、Solaris、BSD、GNU/Linux 等等。如果您完全关心代码库的可移植性，这就是要走的路。
如前所述，有些人似乎喜欢 Scons。如果您熟悉 Python，这可能会在您的工作环境中提供更多的一致性。
Ruby 还有一种称为 Rake 的元构建系统，它本身就很酷，对于已经熟悉 Ruby 的人来说非常方便。