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.

make is a GNU command, so the only way you can get it on Windows is installing a Windows version like the one provided by GNUWin32. Anyway, there are several options for getting that:

1. Directly download from Make for Windows

2. Using Chocolatey. First, you need to install this package manager. Once installed, you simply need to install make (you may need to run it in an elevated/administrator command prompt):

   choco install make
   

3. Another recommended option is installing a Windows Subsystem for Linux (WSL or WSL 2), so you'll have a Linux distribution of your choice embedded in Windows 10, where you'll be able to install make, gcc, and all the tools you need to build C programs.

4. For older Windows versions (Microsoft Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, or Windows 7 with msvcrt.dll) you can use GnuWin32.

An outdated alternative was MinGW, but the project seems to be abandoned, so it's better to go for one of the previous choices.

Normally in UNIX systems the headers go to $PREFIX/include, library files go to $PREFIX/lib, where PREFIX can be /usr or /usr/local or whatever. In linux, if you install your library to these directories it will be found by gcc as you want with just gcc my_source.c -lunixlib.

The PREFIX environment variable is commonly used by various build tools to supply that prefix.

I would also recommend to use DESTDIR variable, it is used by Debian packaging tools at least.

So, the makefile would be like:

# PREFIX is environment variable, but if it is not set, then set default value
ifeq ($(PREFIX),)
    PREFIX := /usr/local
endif

install: unixlib.a
    install -d $(DESTDIR)$(PREFIX)/lib/
    install -m 644 unixlib.a $(DESTDIR)$(PREFIX)/lib/
    install -d $(DESTDIR)$(PREFIX)/include/
    install -m 644 unixlib.h $(DESTDIR)$(PREFIX)/include/

Note, the install -d ... is used just in case if directory does not exist in the supplied DESTDIR for example.

You can also have a look at my non-recursive template for make to find some hints: https://github.com/cppfw/prorab/blob/master/src/prorab.mk

The commands that are executed by make install (or any invocation of make) are defined in the Makefile (and files included by the Makefile). For simple programs, you can just look for a line install: and see the commands in the lines below. But makefiles can also be quite complicated and scattered across various subdirectories. For details, see the manual for make, or an introduction to make.

As @Romeo Ninov wrote, you can also use the command make -n install so see what commands would be executed. Beware that for larger makefiles this output may not be accurate, and if you haven't built the program yet it will likely show you all the commands to build before showing the commands to install.

Run the command:

sudo apt-get install build-essential

Chances are you will need things like gcc to actually do the building so you might as well install those as well. The build-essential package will install other tools used along with make.

There is no rule but usually /usr/local (i.e., /usr/local/bin for binaries).

You can also specify where do you want to install with the --prefix option. For example

./configure --prefix /home/myuser

will install the software in your home directory.

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.

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.

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.