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.

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.

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.

Make is a general purpose workflow program, usually used for compilation. But it can be used for anything.

When you do something like "make all", the make program executes a rule named "all" from a file in current directory named "Makefile". This rule usually calls the compiler to compile some source code into binaries.

When you do "make install", the make program takes the binaries from the previous step and copies them into some appropriate locations so that they can be accessed. Unlike on Windows, installation just requires copying some libraries and executables and there is no registry requirement as such. In short, "make install" just copies compiled files into appropriate locations.

Avoid making local installs into system directories. The system directories eg /usr, are reserved for the package management system to use. By definition, if you are doing make install that means you are making a local install, and if you need to do sudo make install that means you don't have permission to wherever you are writing.

So, if you are getting permission errors with make install, check and see whether you are trying to install into system directories, and install into /usr/local or similar instead. /usr/local is reserved for local installations. You may need to give yourself permission to write to /usr/local, but this is usually easily done. On Debian this can be done by adding yourself to the staff group. Better still, find or create a binary package, and install that instead. That way you can easily keep track of installed packages and obtain the other benefits of package management.

Note that the package management system conversely does not install into /usr/local, per the FHS. See Section 9.1 of the Debian Policy Manual- File system hierarchy for an overview.

./configure runs a script named "configure" in the current directory. make runs the program "make" in your path, and make install runs it again with the argument "install".

Generally, the "configure" script was generated by a collection of programs known as "autotools". It checks your system and tries to generate a makefile (see below) appropriate for your system. It often succeeds.

This makefile it creates (usually called "Makefile", note the capital "M") is used by the program make (on Linux it's probably GNU's make, but there are other versions) to actually compile the software.

The make install command invokes make again, after the software is built, and tells it to execute the series of commands defined as "install" in the makefile.

These things are all conventional, so there's no guarantee that any random file named "configure" will actually do that, or that the target named "install" in a makefile will actually install software, but that's what most people expect from a file named "configure" in somebody's source directory: that it will generate a makefile to compile the program.

Because each step does different things

Prepare(setup) environment for building

./configure

This script has lots of options that you should change. Like --prefix or --with-dir=/foo. That means every system has a different configuration. Also ./configure checks for missing libraries that should be installed. Anything wrong here causes not to build your application. That's why distros have packages that are installed on different places, because every distro thinks it's better to install certain libraries and files to certain directories. It is said to run ./configure, but in fact you should change it always.

For example have a look at the Arch Linux packages site. Here you'll see that any package uses a different configure parameter (assume they are using autotools for the build system).

Building the system

make

This is actually make all by default. And every make has different actions to do. Some do building, some do tests after building, some do checkout from external SCM repositories. Usually you don't have to give any parameters, but again some packages execute them differently.

Install to the system

make install

This installs the package in the place specified with configure. If you want you can specify ./configure to point to your home directory. However, lots of configure options are pointing to /usr or /usr/local. That means then you have to use actually sudo make install because only root can copy files to /usr and /usr/local.

Now you see that each step is a pre-requirement for next step. Each step is a preparation to make things work in a problemless flow. Distros use this metaphor to build packages (like RPM, deb, etc.).

Here you'll see that each step is actually a different state. That's why package managers have different wrappers. Below is an example of a wrapper that lets you build the whole package in one step. But remember that each application has a different wrapper (actually these wrappers have a name like spec, PKGBUILD, etc.):

def setup:
... #use ./configure if autotools is used

def build:
... #use make if autotools is used

def install:
... #use make all if autotools is used

Here one can use autotools, that means ./configure, make and make install. But another one can use SCons, Python related setup or something different.

As you see splitting each state makes things much easier for maintaining and deployment, especially for package maintainers and distros.

./configure

tells you whether are quite ready to build the application. It will check if you have everything needed to build the application, and, if it sees any critical errors it will inform you.

make

builds (compiles) the source code. Compiler compiles the code, but, most of the times, the code cannot stand alone, it requires external libraries (usually provided by ubuntu packages) to be installed. After this step the executable(s) of this specific application you are trying to install will be created.

sudo make install

moves all the needed for the application files to the appropriate system directories. This has to be done after make because the executables of the application have been created and can be moved to the appropriate system directory (e.g. /usr/bin/) for later use.

Libraries are necessary, because they allow a programmer to use code made by other people to achieve certain things. i.e. if I wanted to do some disk formatting in my program, I could use the libs someone already wrote to do the formatting, and I just have to make my program call those libraries. If that person finds an issue in their library, they can fix it, and it will fix it in my program too. This is how open-source software can be written so fast and be so stable.

make looks for the first target in the Makefile. (GNU Make allows configuring this.)

make install looks for a target named exactly "install".

Technically, there is no reason why not - this really is based on how the makefile was set up. It is all designed around dependencies. If the 'install' target is made dependent on the rest of the product, then it would implicitly build the product as you are thinking.

The reason they are separated out is that you are usually going to do a 'make' as the unprivileged developer, and do the 'make install' with elevated privs. Usually you don't want to mix those actions.

dpkg is a program on a Debian/Ubuntu or any derivative distribution for installing already packaged applications. The Difference is very simple, a .deb file is a compiled package of application binaries. It has inbuilt logic for placing the different files indifferent directories.

For example, the executable for the application goes into /usr/bin, However the point to note here is that .deb is a packaged binary file which contains compiled software. You do not get to see the source, Hence Many Companies tend to publish their proprietary software in .deb/.rpm format.One such example is Insync, another is Crossover for Linux. Both these are proprietary but distributed as a .deb or a .rpm file.

Here is the gist.

dpkg -i

Means you are installing a compiled and packaged application to run on any Linux distribution which uses .deb format for installing packages.

and

./configure make make install

Means that you have the source code for the application which you are installing. You are now compiling manually by using the compiler(configure and then followed by make.) on the system rather than the package manager. The make install command will then install the software on the system. this method works regardless of the distribution you are installing on.

When you call make with arguments, you are giving it a list of targets.

There is some discussion of this in the Upgrading Ports section of the FreeBSD Handbook where it says:

Unlike the usual make install clean command, it will upgrade all
the dependencies prior to building and installing the selected
port.

[...]

Note: You can save two extra steps by just running make install
clean instead of make, make install and make clean as three
separate steps.

Also, as a side note: Don't build your package as root unless you really need to. In general you should work in an unprivileged account and then as a final step you can do sudo make install if you have to. It would be better, though, to add the unprivileged user to a group with write-access to the install directories, or even better to install it into a non-system area (for example, with ./configure you can use --prefix=) since most systems, whether Linux or BSD, usually have packages and a packaging system that is used to install software.