When you first learn about all this "cross compiling and porting stuff", you are likely to be confused. Most of this is because there are two different terminologies in use for identifying architectures, the one used by the GNU project's software, and the one used colloquially.
Most of the normal work around porting is cross-compiling user software, not compilers, and people have gotten pretty used to calling the machine they are working on the "host" system, and the machine they are porting to is called the "target". However, when we are building a toolchain, we suddenly have three architectures -- the one on which we are building the toolchain, the system where the toolchain should run, and the system "target"ted. To avoid confusion (right...), these are called the "build", "host" and "target" systems in GNU terminology. As most software isn't toolchains, they do not have a "target" architecture, only "build" and "host" (which are also known as the "host" and "target" systems).
Through the rest of the document, I'm going to use the more "formal" way, since it has all three and I'm also going to talk about toolchains.
Cross compiling in a nutshell
As a general rule, any software project will only know about "build" and "host" architectures, with the exception of meta-projects that do not have source code on their own but rather manage a larger build (like GNU's "toplevel" project, which is what you see at the top of the gcc, gdb and binutils source trees when you unpack them). These are needed every time it is necessary to build code for multiple different architectures in one compile run, such as when some tool needs to be run to generate parts of the source code for the final binary and that tool is shipped along with the rest of the sources.