Building a code
Any non-trivial software is typically built using make files or build scripts. These then ship with the program. When writing build scripts, try to stick to the mainstream, GNU conventions. That is, to build the program you should be able to just run:
./configure make make install
configure sets up the build system; it can take options such as --prefix to declare where the program is to be installed. ./configure --help should explain all the options. make then builds the program. make install will install the program (this may require root or administrator privileges, depending on where it is installed).
There are two good reasons for sticking to this convention: it makes it easier for people to use, as they are likely to know the tools and secondly people build toolsets around these existing methods: colorised editors and IDEs that call make, etc.
Avoid adding extra shell scripts to the build process. This makes it harder to debug and also harder to parallelise.
The build utility make is available on most platforms, but older Unixes often come with their own proprietary version. Today, the GNU Make (often called gmake) is the most feature-full and usable; it contains many features that render additional helper shell scripts unnecessary, and it is worth getting the GNU Make manual and learning them.
In large projects, different sections of the code are often placed in different subdirectories for easy management. Typically, makefiles are then included in each subdirectory, called from the top-level makefile. This recursive nature loses a lot of dependency information and makes it hard to parallelize the build; to avoid this non-recursive makefiles are recommended. see: http://www.xs4all.nl/~evbergen/nonrecursive-make.html.