为什么要“制造"在“进行安装"之前

本文介绍了为什么要“制造"在“进行安装"之前的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我知道从源代码进行安装的过程是

I know the process of installing from source are.

./configure

make

make install

./configure

make

make install

但是为什么要在/etc/cups/cupsd.conf之前"make" ，为什么不只是"make install" ?

But why "make" before /etc/cups/cupsd.conf, why not just do "make install"?

到目前为止，我的理解是"make"仅将源代码编译成可执行文件，而"make install"实际上将它们放入可执行文件PATH文件夹中，对吗?

My understanding so far is "make" only compile the source into executable file, and "make install" actually place them into executable PATH folder, am I right?

如果我们想在计算机上安装可执行文件，我们可以做

If we want to install executable on the machine, can we just do

./configure

make install

./configure

make install

代替上面显示的3个步骤.

Instead of 3 steps shown above.

推荐答案

运行make时，是在指示它基本上遵循针对特定目标的一组构建步骤.当不带任何参数调用make时，它将运行第一个目标，该目标通常只是编译项目. make install映射到install目标，该目标通常不执行任何操作，只是将二进制文件复制到目标位置.

When you run make, you're instructing it to essentially follow a set of build steps for a particular target. When make is called with no parameters, it runs the first target, which usually simply compiles the project. make install maps to the install target, which usually does nothing more than copy binaries into their destinations.

install目标经常取决于编译目标，因此您只需运行make install即可获得相同的结果. 但是，我可以看到至少有一个很好的理由将它们分开进行:特权分离.

Frequently, the install target depends upon the compilation target, so you can get the same results by just running make install. However, I can see at least one good reason to do them in separate steps: privilege separation.

通常，当您安装软件时，它将进入普通用户没有写访问权的位置(例如/usr/bin和/usr/local/bin).然后，由于安装步骤需要特权升级，因此最终通常实际上必须先运行make然后运行sudo make install.这是"Good Thing™"，因为它允许您将软件作为普通用户进行编译(这实际上对某些项目有所作为)，限制了行为不佳的构建过程的潜在损害范围，并且仅获得root用户安装步骤的权限.

Ordinarily, when you install your software, it goes into locations for which ordinary users do not have write access (like /usr/bin and /usr/local/bin). Often, then, you end up actually having to run make and then sudo make install, as the install step requires a privilege escalation. This is a "Good Thing™", because it allows your software to be compiled as a normal user (which actually makes a difference for some projects), limiting the scope of potential damage for a badly-behaving build procedure, and only obtains root privileges for the install step.