This answer is based on several chat messages I posted, which now serve as an extended summary.
The $PATH Environment Variable
By "immediately available on the command line," I assume you mean that you can run it like name, rather than having to type something like /path/to/name, such as /home/galahad/bin/name or ./name.
Your $PATH environment variable contains a list of :-separated directory names. When you run a command in your shell that contains a / character, it's interpreted as the exact location and name of an executable to run. But when you run a command that does not contain a /, your shell searches the directories in $PATH for executables by that name, and runs the first one it finds. (It may also remember where executables you've run before are located. So, in practice, it does not have to search them each time.)
This is why ./name is the common way to run the executable called name located in the current directory. Running name instead would search the directories in $PATH.
If you run echo "$PATH" you will see something like this, though it may well not be exactly this:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Directories in $PATH don't have to be called bin, but this is common.
Configuring Your Build
When you have source code that is compiled by running ./configure and make, you will usually use make install (or sudo make install) to install it. This copies files from the build directory into the install location. When the thing you are installing provides executable commands, those executables are typically copied into a directory that is in $PATH or that you should consider adding to $PATH.
Although building and installing software is often as simple as running ./configure, make, sometimes make check or make test, and then make install or sudo make install, you will sometimes want to pass options to the configure script to configure the build. In particular, as pfnuesel says, this is how you configure where the software is going to be installed. Even though the make install step actually installs the software, the locations where everything will be installed are typically established in the ./configure step.
The most common option for this is --prefix. The default prefix, when you don't tell configure what to use, is usually /usr/local. (Occasionally, a program or library's source code defaults to some other prefix. Fortunately this is rare.)
So ./configure is usually equivalent to ./configure --prefix=/usr/local. To install software in your home directory, you could use ./configure --prefix=/home/galahad (if /home/galahad is your home directory) or --prefix="$HOME". Then of course you must still build and install the software with make. I should say that not all software that is distributed in source code form is built this way. You should always look for documentation inside the extracted source code archive.
What --prefix Means
When you run ./configure --prefix=directory, you are indicating that the software should be installed under the directory directory. But this rarely, if ever, places loose files in directory. Instead, it places files that serve different purposes in the different subdirectories of directory. If those subdirectories don't exist, it creates them.
Executables usually go in directory/bin, though they may go in directory/sbin if they're commonly used for system administration or they may go (more rarely, these days) in directory/games if they are games. Libraries go in directory/lib or another similarly named directory like directory/lib32. Header files go in directory/include. Manual pages go in directory/man. Data files used by the software go in directory/share.
That's what it means for directory to be a prefix. It's the parent directory that contains the locations in which different files will be installed. It thus appears as a prefix in the absolute paths of most files and directories created by running make install or sudo make install.
There are some exceptions to this. Systemwide configuration files--which are sometimes created when installing the software that will use them, though not always--usually go in /etc. This is not typically affected by specifying a different prefix. Even if you install a lot of software in /usr/local, it will still mostly use /etc, and your /usr/local/etc directory will probably be nonexistent, empty, or contain very few files.
On many systems, you can find more information about typical filesystem layout by running man hier. If you're using a GNU/Linux system you may be interested in the Filesystem Hierarchy Standard.
Where Your System Installs Software
Most of the programs that are part of your system, including programs installed by package managers in the vast majority of GNU/Linux operating systems (GoboLinux being one exception) and some other Unix-like systems, are installed with a prefix of /usr. It is rare that you should pass that prefix to ./configure, because you generally want to avoid conflicts with system-provided software.
/usr is permitted to be on a network share or a partition that is otherwise not yet mounted very early in the boot process. Software that must be accessible at this time is usually installed in /. That's why both /usr/bin and /bin exist and why sh is usually /bin/sh.
Package Management
Most package managers have support for installing binaries (though there are exceptions). Usually when you install software in a GNU/Linux system with your package manager, you are installing binary packages. In this case, the package manager doesn't compile anything itself. However, installation still involves copying or extracting files to locations in the filesystem.
This is what I mean when I say your package manager installs most things with a prefix of /usr. I do not mean it necessarily runs ./configure --prefix=/usr or any ./configure command.
Different operating systems have different package managers. If you're using a distribution like Debian or Ubuntu that is designed for you to use utilities like dpkg, apt-get, and aptitude, then you should not typically attempt to install software with rpm, yum, and dnf.
But the core principle is the same across package managers. When a package manager installs a command, it usually goes in a directory that is expected to be in users' $PATH environment variables. In GNU/Linux systems the package manager usually manages the whole system--except whatever you install yourself in other ways--and thus installs most software with a prefix /usr, thereby placing most executable commands in /usr/bin. (Of course, like running make install or sudo make install, package managers usually install other files to other locations as well.)
-C /is probably easier. – Hauke Laging Sep 02 '17 at 08:38