既然我们可以编写自己的makefile,为什么还要使用像Autotools这样的构建工具呢?

时间:2020-12-15 20:51:38

Recently, I switched my development environment from Windows to Linux. So far, I have only used Visual Studio for C++ development, so many concepts, like make and Autotools, are new to me. I have read the GNU makefile documentation and got almost an idea about it. But I am kind of confused about Autotools.

最近,我将开发环境从Windows切换到了Linux。到目前为止,我只在c++开发中使用过Visual Studio,所以很多概念对我来说都是新的,比如make和Autotools。我已经阅读了GNU makefile文档,并对它有了大致的了解。但是我对自动工具有点困惑。

As far as I know, makefiles are used to make the build process easier.

据我所知,makefile用于简化构建过程。

  1. Why do we need tools like Autotools just for creating the makefiles? Since all knows how to create a makefile, I am not getting the real use of Autotools.
  2. 为什么我们需要像Autotools这样的工具来创建makefile ?因为大家都知道如何创建makefile,所以我并没有真正使用Autotools。
  3. What is the standard? Do we need to use tools like this or would just handwritten makefiles do?
  4. 的标准是什么?我们需要使用这样的工具,还是只使用手写的makefile ?

8 个解决方案

#1


68  

You are talking about two separate but intertwined things here:

你说的是两个分离但又相互交织的东西:

  • Autotools
  • Autotools
  • GNU coding standards
  • GNU编码标准

Within Autotools, you have several projects:

在Autotools中,您有几个项目:

  • Autoconf
  • Autoconf
  • Automake
  • Automake
  • Libtool
  • Libtool

Let's look at each one individually.

让我们分别看看每一个。

Autoconf

Autoconf

Autoconf easily scans an existing tree to find its dependencies and create a configure script that will run under almost any kind of shell. The configure script allows the user to control the build behavior (i.e. --with-foo, --without-foo, --prefix, --sysconfdir, etc..) as well as doing checks to ensure that the system can compile the program.

Autoconf可以轻松地扫描现有的树,以找到它的依赖关系,并创建一个可以在几乎任何类型的shell下运行的配置脚本。configure脚本允许用户控制构建行为(例如-foo, - out-foo, -前缀,-sysconfdir等),并执行检查以确保系统能够编译程序。

Configure generates a config.h file (from a template) which programs can include to work around portability issues. For example, if HAVE_LIBPTHREAD is not defined, use forks instead.

配置生成一个配置。h文件(来自模板),程序可以包含在其中以解决可移植性问题。例如,如果没有定义HAVE_LIBPTHREAD,则使用fork。

I personally use Autoconf on many projects. It usually takes people some time to get used to m4. However, it does save time.

我个人在很多项目上都使用Autoconf。人们通常需要一些时间来适应m4。然而,它确实节省了时间。

You can have makefiles inherit some of the values that configure finds without using automake.

您可以让makefile继承一些配置查找的值,而不使用automake。

Automake

Automake

By providing a short template that describes what programs will be built and what objects need to be linked to build them, Makefiles that adhere to GNU coding standards can automatically be created. This includes dependency handling and all of the required GNU targets.

通过提供一个简短的模板来描述将要构建的程序以及需要链接哪些对象来构建它们,可以自动创建遵循GNU编码标准的makefile。这包括依赖项处理和所有必需的GNU目标。

Some people find this easier. I prefer to write my own makefiles.

有些人觉得这更容易。我更喜欢自己编写makefile。

Libtool

Libtool

Libtool is a very cool tool for simplifying the building and installation of shared libraries on any Unix-like system. Sometimes I use it; other times (especially when just building static link objects) I do it by hand.

Libtool是一种非常酷的工具,它可以简化任何类unix系统上的共享库的构建和安装。有时我使用它;其他时候(特别是在构建静态链接对象时)我是手动操作的。

There are other options too, see * question Alternatives to Autoconf and Autotools?.

还有其他选项,请参见*问题替代Autoconf和Autotools?

In short, you really should use some kind of portable build configuration system if you release your code to the masses. What you use is up to you. GNU software is known to build and run on almost anything. However, you might not need to adhere to such (and sometimes extremely pedantic) standards.

简而言之,如果您向大众发布代码,您确实应该使用某种可移植的构建配置系统。你用什么取决于你。众所周知,GNU软件几乎可以在任何东西上构建和运行。然而,您可能不需要遵循这样(有时甚至是非常迂腐)的标准。

If anything, I'd recommend giving Autoconf a try if you're writing software for POSIX systems. If you need documentation and how-to links, update your question.

如果有的话,我建议您尝试一下Autoconf,如果您正在为POSIX系统编写软件的话。如果您需要文档和操作链接,请更新您的问题。

Edit

编辑

Don't fear m4 :) There is always the Autoconf macro archive. Plenty of examples, or drop in checks. Write your own or use what's tested. Autoconf is far too often confused with Automake. They are two separate things.

不要害怕m4:)总是有自动conf宏归档。大量的例子,或者是勾选。编写自己的或者使用测试过的内容。Autoconf经常与Automake混淆。它们是两个不同的东西。

#2


31  

First of all, the Autotools are not an opaque build system but a loosely coupled tool-chain, as tinkertim already pointed out. Let me just add some thoughts on Autoconf and Automake:

首先,Autotools不是一个不透明的构建系统,而是一个松散耦合的工具链,正如tinkertim已经指出的那样。让我补充一些关于Autoconf和Automake的想法:

Autoconf is the configuration system that creates the configure script based on feature checks that are supposed to work on all kinds of platforms. A lot of system knowledge has gone into its m4 macro database during the 15 years of its existence. On the one hand, I think the latter is the main reason Autotools have not been replaced by something else yet. On the other hand, Autoconf used to be far more important when the target platforms were more heterogeneous and Linux, AIX, HP-UX, SunOS, ..., and a large variety of different processor architecture had to be supported. I don't really see its point if you only want to support recent Linux distributions and Intel-compatible processors.

Autoconf是一个配置系统,它基于功能检查来创建配置脚本,这些功能检查应该在各种平台上运行。在m4宏数据库存在的15年里,大量的系统知识已经进入了它的m4宏数据库。一方面,我认为后者是汽车工具还没有被其他东西取代的主要原因。另一方面,当目标平台更加异构和Linux、AIX、HP-UX、SunOS时,Autoconf更重要。需要支持各种不同的处理器体系结构。如果您只想支持最近的Linux发行版和与intel兼容的处理器,那么我并不认为它有什么意义。

Automake is an abstraction layer for GNU Make and acts as a Makefile generator from simpler templates. A number of projects eventually got rid of the Automake abstraction and reverted to writing Makefiles manually because you lose control over your Makefiles and you might not need all the canned build targets that obfuscate your Makefile.

Automake是GNU的一个抽象层,它作为一个Makefile生成器从更简单的模板中起作用。一些项目最终摆脱了自动化的抽象,并恢复了手工编写Makefile,因为您失去了对Makefile的控制,并且您可能不需要所有的构建目标来混淆您的Makefile。

Now to the alternatives (and I strongly suggest an alternative to Autotools based on your requirements):

现在来看看其他的选择(我强烈建议您根据自己的需求来选择Autotools):

CMake's most notable achievement is replacing AutoTools in KDE. It's probably the closest you can get if you want to have Autoconf-like functionality without m4 idiosyncrasies. It brings Windows support to the table and has proven to be applicable in large projects. My beef with CMake is that it is still a Makefile-generator (at least on Linux) with all its immanent problems (e.g. Makefile debugging, timestamp signatures, implicit dependency order).

CMake最显著的成就是在KDE替换了AutoTools。如果你想拥有没有m4特性的类似autoconf的功能,它可能是你能得到的最接近的。它为表提供了Windows支持,并已被证明适用于大型项目。我对CMake的不满是它仍然是一个Makefile生成器(至少在Linux上是如此),它有所有的内在问题(例如,Makefile调试、时间戳签名、隐式依赖顺序)。

SCons is a Make replacement written in Python. It uses Python scripts as build control files allowing very sophisticated techniques. Unfortunately, its configuration system is not on par with Autoconf. SCons is often used for in-house development when adaptation to specific requirements is more important than following conventions.

SCons是用Python编写的Make替换版本。它使用Python脚本作为构建控制文件,允许非常复杂的技术。不幸的是,它的配置系统与Autoconf不一样。在适应特定需求时,SCons通常用于内部开发,比遵循约定更为重要。

If you really want to stick with Autotools, I strongly suggest to read Recursive Make Considered Harmful and write your own GNU Makefile configured through Autoconf.

如果您真的想继续使用Autotools,我强烈建议您阅读递归Make,并编写通过Autoconf配置的GNU Makefile。

#3


16  

The answers already provided here are good, but I'd strongly recommend not taking the advice to write your own makefile if you have anything resembling a standard C/C++ project. We need the autotools instead of handwritten makefiles because a standard-compliant makefile generated by automake offers a lot of useful targets under well-known names, and providing all these targets by hand is tedious and error-prone.

这里提供的答案很好,但是如果您有类似于标准的C/ c++项目,我强烈建议您不要采纳编写自己的makefile的建议。我们需要autotools而不是手写的makefile,因为automake生成的兼容标准的makefile在众所周知的名称下提供了许多有用的目标,手工提供所有这些目标是冗长且容易出错的。

Firstly, writing a Makefile by hand seems a great idea at first, but most people will not bother to write more than the rules for all, install and maybe clean. automake generates dist, distcheck, clean, distclean, uninstall and all these little helpers. These additional targets are a great boon to the sysadmin that will eventually install your software.

首先,手工编写Makefile似乎是个不错的主意,但大多数人不会费心去编写所有的规则,安装或者清理。automake生成dist、distcheck、clean、distclean、uninstall和所有这些小助手。这些附加的目标对于最终安装您的软件的系统管理员来说是一个巨大的福音。

Secondly, providing all these targets in a portable and flexible way is quite error-prone. I've done a lot of cross-compilation to Windows targets recently, and the autotools performed just great. In contrast to most hand-written files, which were mostly a pain in the ass to compile. Mind you, it is possible to create a good Makefile by hand. But don't overestimate yourself, it takes a lot of experience and knowledge about a bunch of different systems, and automake creates great Makefiles for you right out of the box.

其次,以可移植和灵活的方式提供所有这些目标是非常容易出错的。我最近对Windows目标做了很多交叉编译,autotools的表现非常好。与大多数手写的文件相比,这些文件大部分都是令人头疼的。请注意,用手工创建一个好的Makefile是可能的。但是不要高估你自己,它需要大量的经验和知识关于不同的系统,并且automake为你创建了非常棒的makefile。

Edit: And don't be tempted to use the "alternatives". CMake and friends are a horror to the deployer because they aren't interface-compatible to configure and friends. Every half-way competent sysadmin or developer can do great things like cross-compilation or simple things like setting a prefix out of his head or with a simple --help with a configure script. But you are damned to spend an hour or three when you have to do such things with BJam. Don't get me wrong, BJam is probably a great system under the hood, but it's a pain in the ass to use because there are almost no projects using it and very little and incomplete documentation. autoconf and automake have a huge lead here in terms of established knowledge.

编辑:不要试图使用“替代方案”。CMake和friends对部署人员来说是可怕的,因为它们不兼容接口来配置和好友。每一个有能力的系统管理员或开发人员都可以做一些伟大的事情,比如交叉编译,或者简单的事情,比如在头脑中设置一个前缀,或者使用一个简单的——帮助配置脚本。但是当你必须用BJam做这些事情的时候,你就得花上一三个小时。不要误解我的意思,BJam可能是一个很好的系统,但是使用它是非常麻烦的,因为几乎没有项目使用它,而且很少有不完整的文档。autoconf和automake在现有知识方面拥有巨大的领先优势。

So, even though I'm a bit late with this advice for this question: Do yourself a favor and use the autotools and automake. The syntax might be a bit strange, but they do a way better job than 99% of the developers do on their own.

所以,尽管我对这个问题的建议有点晚了:帮自己一个忙,使用自动工具和自动工具。语法可能有点奇怪,但是它们比99%的开发人员自己做的更好。

#4


9  

For small projects or even for large projects that only run on one platform, handwritten makefiles are the way to go.

对于小型项目,甚至对于只在一个平台上运行的大型项目,最好使用手写的makefile。

Where autotools really shine is when you are compiling for different platforms that require different options. Autotools is frequently the brains behind the typical

当您为需要不同选项的不同平台编译时,autotools真正的亮点是。自动工具通常是典型的大脑。

./configure

. / configure

make

使

make install

制作安装

compilation and install steps for Linux libraries and applications.

为Linux库和应用程序编译和安装步骤。

That said, I find autotools to be a pain and I've been looking for a better system. Lately I've been using bjam, but that also has its drawbacks. Good luck finding what works for you.

也就是说,我觉得自动工具很痛苦,我一直在寻找更好的系统。最近我一直在使用bjam,但它也有缺点。祝你好运,找到适合你的。

#5


6  

Autotools are needed because Makefiles are not guaranteed to work the same across different platforms. If you handwrite a Makefile, and it works on your machine, there is a good chance that it won't on mine.

需要自动工具,因为makefile不能保证在不同的平台上工作。如果您手工编写一个Makefile,并且它在您的机器上工作,那么它很可能不会在我的机器上工作。

#6


5  

Do you know what unix your users will be using? Or even which distribution of Linux? Do you know where they want software installed? Do you know what tools they have, what architecture they want to compile on, how many CPUs they have, how much RAM and disk might be available to them?

您知道您的用户将使用什么unix吗?或者是哪个Linux发行版?你知道他们想在哪里安装软件吗?你知道他们有什么工具,他们想要编译什么架构,他们有多少cpu,有多少RAM和磁盘可用吗?

The *nix world is a cross-platform landscape, and your build and install tools need to deal with that.

*nix世界是一个跨平台的环境,您的构建和安装工具需要处理这个问题。


Mind you, the auto* tools date from an earlier epoch, and there are many valid complaints about them, but the several projects to replace them with more modern alternatives are having trouble developing a lot of momentum.

请注意,auto* tools可以追溯到更早的时代,关于它们有很多合理的抱怨,但是用更现代的替代工具替代它们的几个项目在开发大量的动力方面遇到了麻烦。

Lots of things are like that in the *nix world.

在*nix世界里有很多类似的东西。

#7


1  

Autotools is a disaster.

Autotools是一场灾难。

The generated ./configure script checks for features that have not been present on any Unix system for last 20 years or so. To do this, it spends a huge amount of time.

生成的./configure脚本检查过去20年左右在任何Unix系统上都没有出现的特性。为了做到这一点,它花费了大量的时间。

Running ./configure takes for ages. Although modern server CPUs can have even dozens of cores, and there may be several such CPUs per server, the ./configure is single-threaded. We still have enough years of Moore's law left that the number of CPU cores will go way up as a function of time. So, the time ./configure takes will stay approximately constant whereas parallel build times reduce by a factor of 2 every 2 years due to Moore's law. Or actually, I would say the time ./configure takes might even increase due to increasing software complexity taking advantage of improved hardware.

运行/配置需要很长时间。尽管现代服务器cpu可以拥有几十个内核,而且每个服务器可能有多个这样的cpu,但是/configure是单线程的。我们仍然有足够多年的摩尔定律,CPU内核的数量会随着时间的变化而增加。所以,时间。/配置将保持近似不变,而并行构建时间每2年减少2倍,因为摩尔定律。或者实际上,我想说时间。/configure take甚至可能由于利用改进的硬件增加了软件的复杂性而增加。

The mere act of adding just one file to your project requires you to run automake, autoconf and ./configure which will take ages, and then you'll probably find that since some important files have changed, everything will be recompiled. So add just one file, and make -j${CPUCOUNT} recompiles everything.

仅仅将一个文件添加到项目中,就需要您运行automake、autoconf和/configure,这将花费很长时间,然后您可能会发现,由于一些重要的文件已经更改,所有的文件都将重新编译。因此只需添加一个文件,并使-j${CPUCOUNT}重新编译所有内容。

And about make -j${CPUCOUNT}. The generated build system is a recursive one. Recursive make has for a long amount of time been considered harmful.

和让- j $ { CPUCOUNT }。生成的构建系统是递归的。递归make在很长一段时间内被认为是有害的。

Then when you install the software that has been compiled, you'll find that it doesn't work. (Want proof? Clone protobuf repository from Github, check out commit 9f80df026933901883da1d556b38292e14836612, install it to a Debian or Ubuntu system, and hey presto: protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory -- since it's in /usr/local/lib and not /usr/lib; workaround is to do export LD_RUN_PATH=/usr/local/lib before typing make).

然后,当您安装已编译的软件时,您会发现它不能工作。(想要证据吗?从Github上克隆原生buf存储库,检查commit 9f80df026933901883da1d556b38292e14836612,将其安装到Debian或Ubuntu系统中,并在加载共享库时出现错误:libprotoc.so。15:不能打开共享对象文件:没有这样的文件或目录——因为它位于/usr/local/lib中,而不是/usr/lib;解决方法是在输入make之前导出LD_RUN_PATH=/usr/local/lib)。

The theory is that by using autotools, you could create a software package that can be compiled on Linux, FreeBSD, NetBSD, OpenBSD, DragonflyBSD and other operating systems. The fact? Every non-Linux system to build packages from source has numerous patch files in their repository to work around autotools bugs. Just take a look at e.g. FreeBSD /usr/ports: it's full of patches. So, it would have been as easy to create a small patch for a non-autotools build system on a per project basis than to create a small patch for an autotools build system on a per project basis. Or perhaps even easier, as standard make is much easier to use than autotools.

其原理是,通过使用autotools,您可以创建一个软件包,可以在Linux、FreeBSD、NetBSD、OpenBSD、DragonflyBSD和其他操作系统上编译。事实吗?每个从源代码构建包的非linux系统在它们的存储库中都有许多补丁文件,用于处理自动工具的错误。看看FreeBSD /usr/ports:它充满了补丁。因此,在每个项目的基础上为非自动工具构建系统创建一个小补丁,要比在每个项目的基础上为自动工具构建系统创建一个小补丁简单得多。或者可能更简单,因为标准make比自动工具更容易使用。

The fact is, if you create your own build system based on standard make (and make it inclusive and not recursive, following the recommendations of the "Recursive make considered harmful" paper), things work in a much better manner. Also, your build time goes down by an order of magnitude, perhaps even two orders of magnitude if your project is very small project of 10-100 C language files and you have dozens of cores per CPU and multiple CPUs. It's also much easier to interface custom automatic code generation tools with a custom build system based on standard make instead of dealing with the m4 mess of autotools. With standard make, you can at least type a shell command into the Makefile.

事实是,如果您基于标准make创建您自己的构建系统(并使其具有包容性而非递归性,遵循“递归使认为有害”的建议),那么事情将以更好的方式工作。此外,如果您的项目是由10-100个C语言文件组成的非常小的项目,并且每个CPU和多个CPU都有几十个内核,那么您的构建时间将减少一个数量级,甚至可能减少两个数量级。使用基于standard make的自定义构建系统与自定义自动代码生成工具进行交互也要容易得多,而不是处理autotools的m4混乱。使用标准make,您至少可以在Makefile中输入shell命令。

So, to answer your question: why use autotools? Answer: there is no reason to do so. Autotools has been obsolete since when commercial Unix has become obsolete. And the advent of multi-core CPUs has made autotools even more obsolete. Why programmers haven't realized that yet, is a mystery. I'll happily use standard make on my build systems, thank you. Yes, it takes some amount of work to generate the dependency files for C language header inclusion, but the amount of work is saved by not having to fight with autotools.

那么,要回答你的问题:为什么要使用自动工具?答:没有理由这么做。自商业Unix过时以来,自动工具就已经过时了。多核cpu的出现使自动工具变得更加过时。为什么程序员还没有意识到这一点呢?这是一个谜。我很乐意在我的构建系统上使用标准make,谢谢。是的,生成包含C语言头的依赖文件需要花费大量的工作,但是不用与autotools进行斗争就可以节省大量的工作。

#8


0  

I dont feel I am an expert to answer this but still give you a bit analogy with my experience.

我不觉得我是回答这个问题的专家,但我的经验仍然可以给你一些类比。

Because upto some extent it is similar to why we should write Embedded Codes in C language(High Level language) rather then writing in Assembly Language. Both solves the same purpose but latter is more lenghty, tedious ,time consuming and more error prone(unless you know ISA of the processor very well) . Same is the case with Automake tool and writing your own makefile. Writing Makefile.am and configure.ac is pretty simple than writing individual project Makefile.

因为在某种程度上,它类似于为什么我们应该用C语言(高级语言)编写嵌入式代码,而不是用汇编语言编写代码。两者都解决了相同的目的,但是后者更华丽、乏味、耗时,而且更容易出错(除非您非常熟悉ISA的处理器)。Automake工具和编写自己的makefile也是如此。编写Makefile。和配置。ac比编写单个项目Makefile要简单得多。

#1


68  

You are talking about two separate but intertwined things here:

你说的是两个分离但又相互交织的东西:

  • Autotools
  • Autotools
  • GNU coding standards
  • GNU编码标准

Within Autotools, you have several projects:

在Autotools中,您有几个项目:

  • Autoconf
  • Autoconf
  • Automake
  • Automake
  • Libtool
  • Libtool

Let's look at each one individually.

让我们分别看看每一个。

Autoconf

Autoconf

Autoconf easily scans an existing tree to find its dependencies and create a configure script that will run under almost any kind of shell. The configure script allows the user to control the build behavior (i.e. --with-foo, --without-foo, --prefix, --sysconfdir, etc..) as well as doing checks to ensure that the system can compile the program.

Autoconf可以轻松地扫描现有的树,以找到它的依赖关系,并创建一个可以在几乎任何类型的shell下运行的配置脚本。configure脚本允许用户控制构建行为(例如-foo, - out-foo, -前缀,-sysconfdir等),并执行检查以确保系统能够编译程序。

Configure generates a config.h file (from a template) which programs can include to work around portability issues. For example, if HAVE_LIBPTHREAD is not defined, use forks instead.

配置生成一个配置。h文件(来自模板),程序可以包含在其中以解决可移植性问题。例如,如果没有定义HAVE_LIBPTHREAD,则使用fork。

I personally use Autoconf on many projects. It usually takes people some time to get used to m4. However, it does save time.

我个人在很多项目上都使用Autoconf。人们通常需要一些时间来适应m4。然而,它确实节省了时间。

You can have makefiles inherit some of the values that configure finds without using automake.

您可以让makefile继承一些配置查找的值,而不使用automake。

Automake

Automake

By providing a short template that describes what programs will be built and what objects need to be linked to build them, Makefiles that adhere to GNU coding standards can automatically be created. This includes dependency handling and all of the required GNU targets.

通过提供一个简短的模板来描述将要构建的程序以及需要链接哪些对象来构建它们,可以自动创建遵循GNU编码标准的makefile。这包括依赖项处理和所有必需的GNU目标。

Some people find this easier. I prefer to write my own makefiles.

有些人觉得这更容易。我更喜欢自己编写makefile。

Libtool

Libtool

Libtool is a very cool tool for simplifying the building and installation of shared libraries on any Unix-like system. Sometimes I use it; other times (especially when just building static link objects) I do it by hand.

Libtool是一种非常酷的工具,它可以简化任何类unix系统上的共享库的构建和安装。有时我使用它;其他时候(特别是在构建静态链接对象时)我是手动操作的。

There are other options too, see * question Alternatives to Autoconf and Autotools?.

还有其他选项,请参见*问题替代Autoconf和Autotools?

In short, you really should use some kind of portable build configuration system if you release your code to the masses. What you use is up to you. GNU software is known to build and run on almost anything. However, you might not need to adhere to such (and sometimes extremely pedantic) standards.

简而言之,如果您向大众发布代码,您确实应该使用某种可移植的构建配置系统。你用什么取决于你。众所周知,GNU软件几乎可以在任何东西上构建和运行。然而,您可能不需要遵循这样(有时甚至是非常迂腐)的标准。

If anything, I'd recommend giving Autoconf a try if you're writing software for POSIX systems. If you need documentation and how-to links, update your question.

如果有的话,我建议您尝试一下Autoconf,如果您正在为POSIX系统编写软件的话。如果您需要文档和操作链接,请更新您的问题。

Edit

编辑

Don't fear m4 :) There is always the Autoconf macro archive. Plenty of examples, or drop in checks. Write your own or use what's tested. Autoconf is far too often confused with Automake. They are two separate things.

不要害怕m4:)总是有自动conf宏归档。大量的例子,或者是勾选。编写自己的或者使用测试过的内容。Autoconf经常与Automake混淆。它们是两个不同的东西。

#2


31  

First of all, the Autotools are not an opaque build system but a loosely coupled tool-chain, as tinkertim already pointed out. Let me just add some thoughts on Autoconf and Automake:

首先,Autotools不是一个不透明的构建系统,而是一个松散耦合的工具链,正如tinkertim已经指出的那样。让我补充一些关于Autoconf和Automake的想法:

Autoconf is the configuration system that creates the configure script based on feature checks that are supposed to work on all kinds of platforms. A lot of system knowledge has gone into its m4 macro database during the 15 years of its existence. On the one hand, I think the latter is the main reason Autotools have not been replaced by something else yet. On the other hand, Autoconf used to be far more important when the target platforms were more heterogeneous and Linux, AIX, HP-UX, SunOS, ..., and a large variety of different processor architecture had to be supported. I don't really see its point if you only want to support recent Linux distributions and Intel-compatible processors.

Autoconf是一个配置系统,它基于功能检查来创建配置脚本,这些功能检查应该在各种平台上运行。在m4宏数据库存在的15年里,大量的系统知识已经进入了它的m4宏数据库。一方面,我认为后者是汽车工具还没有被其他东西取代的主要原因。另一方面,当目标平台更加异构和Linux、AIX、HP-UX、SunOS时,Autoconf更重要。需要支持各种不同的处理器体系结构。如果您只想支持最近的Linux发行版和与intel兼容的处理器,那么我并不认为它有什么意义。

Automake is an abstraction layer for GNU Make and acts as a Makefile generator from simpler templates. A number of projects eventually got rid of the Automake abstraction and reverted to writing Makefiles manually because you lose control over your Makefiles and you might not need all the canned build targets that obfuscate your Makefile.

Automake是GNU的一个抽象层,它作为一个Makefile生成器从更简单的模板中起作用。一些项目最终摆脱了自动化的抽象,并恢复了手工编写Makefile,因为您失去了对Makefile的控制,并且您可能不需要所有的构建目标来混淆您的Makefile。

Now to the alternatives (and I strongly suggest an alternative to Autotools based on your requirements):

现在来看看其他的选择(我强烈建议您根据自己的需求来选择Autotools):

CMake's most notable achievement is replacing AutoTools in KDE. It's probably the closest you can get if you want to have Autoconf-like functionality without m4 idiosyncrasies. It brings Windows support to the table and has proven to be applicable in large projects. My beef with CMake is that it is still a Makefile-generator (at least on Linux) with all its immanent problems (e.g. Makefile debugging, timestamp signatures, implicit dependency order).

CMake最显著的成就是在KDE替换了AutoTools。如果你想拥有没有m4特性的类似autoconf的功能,它可能是你能得到的最接近的。它为表提供了Windows支持,并已被证明适用于大型项目。我对CMake的不满是它仍然是一个Makefile生成器(至少在Linux上是如此),它有所有的内在问题(例如,Makefile调试、时间戳签名、隐式依赖顺序)。

SCons is a Make replacement written in Python. It uses Python scripts as build control files allowing very sophisticated techniques. Unfortunately, its configuration system is not on par with Autoconf. SCons is often used for in-house development when adaptation to specific requirements is more important than following conventions.

SCons是用Python编写的Make替换版本。它使用Python脚本作为构建控制文件,允许非常复杂的技术。不幸的是,它的配置系统与Autoconf不一样。在适应特定需求时,SCons通常用于内部开发,比遵循约定更为重要。

If you really want to stick with Autotools, I strongly suggest to read Recursive Make Considered Harmful and write your own GNU Makefile configured through Autoconf.

如果您真的想继续使用Autotools,我强烈建议您阅读递归Make,并编写通过Autoconf配置的GNU Makefile。

#3


16  

The answers already provided here are good, but I'd strongly recommend not taking the advice to write your own makefile if you have anything resembling a standard C/C++ project. We need the autotools instead of handwritten makefiles because a standard-compliant makefile generated by automake offers a lot of useful targets under well-known names, and providing all these targets by hand is tedious and error-prone.

这里提供的答案很好,但是如果您有类似于标准的C/ c++项目,我强烈建议您不要采纳编写自己的makefile的建议。我们需要autotools而不是手写的makefile,因为automake生成的兼容标准的makefile在众所周知的名称下提供了许多有用的目标,手工提供所有这些目标是冗长且容易出错的。

Firstly, writing a Makefile by hand seems a great idea at first, but most people will not bother to write more than the rules for all, install and maybe clean. automake generates dist, distcheck, clean, distclean, uninstall and all these little helpers. These additional targets are a great boon to the sysadmin that will eventually install your software.

首先,手工编写Makefile似乎是个不错的主意,但大多数人不会费心去编写所有的规则,安装或者清理。automake生成dist、distcheck、clean、distclean、uninstall和所有这些小助手。这些附加的目标对于最终安装您的软件的系统管理员来说是一个巨大的福音。

Secondly, providing all these targets in a portable and flexible way is quite error-prone. I've done a lot of cross-compilation to Windows targets recently, and the autotools performed just great. In contrast to most hand-written files, which were mostly a pain in the ass to compile. Mind you, it is possible to create a good Makefile by hand. But don't overestimate yourself, it takes a lot of experience and knowledge about a bunch of different systems, and automake creates great Makefiles for you right out of the box.

其次,以可移植和灵活的方式提供所有这些目标是非常容易出错的。我最近对Windows目标做了很多交叉编译,autotools的表现非常好。与大多数手写的文件相比,这些文件大部分都是令人头疼的。请注意,用手工创建一个好的Makefile是可能的。但是不要高估你自己,它需要大量的经验和知识关于不同的系统,并且automake为你创建了非常棒的makefile。

Edit: And don't be tempted to use the "alternatives". CMake and friends are a horror to the deployer because they aren't interface-compatible to configure and friends. Every half-way competent sysadmin or developer can do great things like cross-compilation or simple things like setting a prefix out of his head or with a simple --help with a configure script. But you are damned to spend an hour or three when you have to do such things with BJam. Don't get me wrong, BJam is probably a great system under the hood, but it's a pain in the ass to use because there are almost no projects using it and very little and incomplete documentation. autoconf and automake have a huge lead here in terms of established knowledge.

编辑:不要试图使用“替代方案”。CMake和friends对部署人员来说是可怕的,因为它们不兼容接口来配置和好友。每一个有能力的系统管理员或开发人员都可以做一些伟大的事情,比如交叉编译,或者简单的事情,比如在头脑中设置一个前缀,或者使用一个简单的——帮助配置脚本。但是当你必须用BJam做这些事情的时候,你就得花上一三个小时。不要误解我的意思,BJam可能是一个很好的系统,但是使用它是非常麻烦的,因为几乎没有项目使用它,而且很少有不完整的文档。autoconf和automake在现有知识方面拥有巨大的领先优势。

So, even though I'm a bit late with this advice for this question: Do yourself a favor and use the autotools and automake. The syntax might be a bit strange, but they do a way better job than 99% of the developers do on their own.

所以,尽管我对这个问题的建议有点晚了:帮自己一个忙,使用自动工具和自动工具。语法可能有点奇怪,但是它们比99%的开发人员自己做的更好。

#4


9  

For small projects or even for large projects that only run on one platform, handwritten makefiles are the way to go.

对于小型项目,甚至对于只在一个平台上运行的大型项目,最好使用手写的makefile。

Where autotools really shine is when you are compiling for different platforms that require different options. Autotools is frequently the brains behind the typical

当您为需要不同选项的不同平台编译时,autotools真正的亮点是。自动工具通常是典型的大脑。

./configure

. / configure

make

使

make install

制作安装

compilation and install steps for Linux libraries and applications.

为Linux库和应用程序编译和安装步骤。

That said, I find autotools to be a pain and I've been looking for a better system. Lately I've been using bjam, but that also has its drawbacks. Good luck finding what works for you.

也就是说,我觉得自动工具很痛苦,我一直在寻找更好的系统。最近我一直在使用bjam,但它也有缺点。祝你好运,找到适合你的。

#5


6  

Autotools are needed because Makefiles are not guaranteed to work the same across different platforms. If you handwrite a Makefile, and it works on your machine, there is a good chance that it won't on mine.

需要自动工具,因为makefile不能保证在不同的平台上工作。如果您手工编写一个Makefile,并且它在您的机器上工作,那么它很可能不会在我的机器上工作。

#6


5  

Do you know what unix your users will be using? Or even which distribution of Linux? Do you know where they want software installed? Do you know what tools they have, what architecture they want to compile on, how many CPUs they have, how much RAM and disk might be available to them?

您知道您的用户将使用什么unix吗?或者是哪个Linux发行版?你知道他们想在哪里安装软件吗?你知道他们有什么工具,他们想要编译什么架构,他们有多少cpu,有多少RAM和磁盘可用吗?

The *nix world is a cross-platform landscape, and your build and install tools need to deal with that.

*nix世界是一个跨平台的环境,您的构建和安装工具需要处理这个问题。


Mind you, the auto* tools date from an earlier epoch, and there are many valid complaints about them, but the several projects to replace them with more modern alternatives are having trouble developing a lot of momentum.

请注意,auto* tools可以追溯到更早的时代,关于它们有很多合理的抱怨,但是用更现代的替代工具替代它们的几个项目在开发大量的动力方面遇到了麻烦。

Lots of things are like that in the *nix world.

在*nix世界里有很多类似的东西。

#7


1  

Autotools is a disaster.

Autotools是一场灾难。

The generated ./configure script checks for features that have not been present on any Unix system for last 20 years or so. To do this, it spends a huge amount of time.

生成的./configure脚本检查过去20年左右在任何Unix系统上都没有出现的特性。为了做到这一点,它花费了大量的时间。

Running ./configure takes for ages. Although modern server CPUs can have even dozens of cores, and there may be several such CPUs per server, the ./configure is single-threaded. We still have enough years of Moore's law left that the number of CPU cores will go way up as a function of time. So, the time ./configure takes will stay approximately constant whereas parallel build times reduce by a factor of 2 every 2 years due to Moore's law. Or actually, I would say the time ./configure takes might even increase due to increasing software complexity taking advantage of improved hardware.

运行/配置需要很长时间。尽管现代服务器cpu可以拥有几十个内核,而且每个服务器可能有多个这样的cpu,但是/configure是单线程的。我们仍然有足够多年的摩尔定律,CPU内核的数量会随着时间的变化而增加。所以,时间。/配置将保持近似不变,而并行构建时间每2年减少2倍,因为摩尔定律。或者实际上,我想说时间。/configure take甚至可能由于利用改进的硬件增加了软件的复杂性而增加。

The mere act of adding just one file to your project requires you to run automake, autoconf and ./configure which will take ages, and then you'll probably find that since some important files have changed, everything will be recompiled. So add just one file, and make -j${CPUCOUNT} recompiles everything.

仅仅将一个文件添加到项目中,就需要您运行automake、autoconf和/configure,这将花费很长时间,然后您可能会发现,由于一些重要的文件已经更改,所有的文件都将重新编译。因此只需添加一个文件,并使-j${CPUCOUNT}重新编译所有内容。

And about make -j${CPUCOUNT}. The generated build system is a recursive one. Recursive make has for a long amount of time been considered harmful.

和让- j $ { CPUCOUNT }。生成的构建系统是递归的。递归make在很长一段时间内被认为是有害的。

Then when you install the software that has been compiled, you'll find that it doesn't work. (Want proof? Clone protobuf repository from Github, check out commit 9f80df026933901883da1d556b38292e14836612, install it to a Debian or Ubuntu system, and hey presto: protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory -- since it's in /usr/local/lib and not /usr/lib; workaround is to do export LD_RUN_PATH=/usr/local/lib before typing make).

然后,当您安装已编译的软件时,您会发现它不能工作。(想要证据吗?从Github上克隆原生buf存储库,检查commit 9f80df026933901883da1d556b38292e14836612,将其安装到Debian或Ubuntu系统中,并在加载共享库时出现错误:libprotoc.so。15:不能打开共享对象文件:没有这样的文件或目录——因为它位于/usr/local/lib中,而不是/usr/lib;解决方法是在输入make之前导出LD_RUN_PATH=/usr/local/lib)。

The theory is that by using autotools, you could create a software package that can be compiled on Linux, FreeBSD, NetBSD, OpenBSD, DragonflyBSD and other operating systems. The fact? Every non-Linux system to build packages from source has numerous patch files in their repository to work around autotools bugs. Just take a look at e.g. FreeBSD /usr/ports: it's full of patches. So, it would have been as easy to create a small patch for a non-autotools build system on a per project basis than to create a small patch for an autotools build system on a per project basis. Or perhaps even easier, as standard make is much easier to use than autotools.

其原理是,通过使用autotools,您可以创建一个软件包,可以在Linux、FreeBSD、NetBSD、OpenBSD、DragonflyBSD和其他操作系统上编译。事实吗?每个从源代码构建包的非linux系统在它们的存储库中都有许多补丁文件,用于处理自动工具的错误。看看FreeBSD /usr/ports:它充满了补丁。因此,在每个项目的基础上为非自动工具构建系统创建一个小补丁,要比在每个项目的基础上为自动工具构建系统创建一个小补丁简单得多。或者可能更简单,因为标准make比自动工具更容易使用。

The fact is, if you create your own build system based on standard make (and make it inclusive and not recursive, following the recommendations of the "Recursive make considered harmful" paper), things work in a much better manner. Also, your build time goes down by an order of magnitude, perhaps even two orders of magnitude if your project is very small project of 10-100 C language files and you have dozens of cores per CPU and multiple CPUs. It's also much easier to interface custom automatic code generation tools with a custom build system based on standard make instead of dealing with the m4 mess of autotools. With standard make, you can at least type a shell command into the Makefile.

事实是,如果您基于标准make创建您自己的构建系统(并使其具有包容性而非递归性,遵循“递归使认为有害”的建议),那么事情将以更好的方式工作。此外,如果您的项目是由10-100个C语言文件组成的非常小的项目,并且每个CPU和多个CPU都有几十个内核,那么您的构建时间将减少一个数量级,甚至可能减少两个数量级。使用基于standard make的自定义构建系统与自定义自动代码生成工具进行交互也要容易得多,而不是处理autotools的m4混乱。使用标准make,您至少可以在Makefile中输入shell命令。

So, to answer your question: why use autotools? Answer: there is no reason to do so. Autotools has been obsolete since when commercial Unix has become obsolete. And the advent of multi-core CPUs has made autotools even more obsolete. Why programmers haven't realized that yet, is a mystery. I'll happily use standard make on my build systems, thank you. Yes, it takes some amount of work to generate the dependency files for C language header inclusion, but the amount of work is saved by not having to fight with autotools.

那么,要回答你的问题:为什么要使用自动工具?答:没有理由这么做。自商业Unix过时以来,自动工具就已经过时了。多核cpu的出现使自动工具变得更加过时。为什么程序员还没有意识到这一点呢?这是一个谜。我很乐意在我的构建系统上使用标准make,谢谢。是的,生成包含C语言头的依赖文件需要花费大量的工作,但是不用与autotools进行斗争就可以节省大量的工作。

#8


0  

I dont feel I am an expert to answer this but still give you a bit analogy with my experience.

我不觉得我是回答这个问题的专家,但我的经验仍然可以给你一些类比。

Because upto some extent it is similar to why we should write Embedded Codes in C language(High Level language) rather then writing in Assembly Language. Both solves the same purpose but latter is more lenghty, tedious ,time consuming and more error prone(unless you know ISA of the processor very well) . Same is the case with Automake tool and writing your own makefile. Writing Makefile.am and configure.ac is pretty simple than writing individual project Makefile.

因为在某种程度上,它类似于为什么我们应该用C语言(高级语言)编写嵌入式代码,而不是用汇编语言编写代码。两者都解决了相同的目的,但是后者更华丽、乏味、耗时,而且更容易出错(除非您非常熟悉ISA的处理器)。Automake工具和编写自己的makefile也是如此。编写Makefile。和配置。ac比编写单个项目Makefile要简单得多。