An executable for a project is generated in two steps:
These steps are collectively known as Building. Some other steps may also be involved in the build process, but for the sake of simplicity, we will only look at these two steps.
Compiling is the step in which object files are generated from their corresponding source files. For instance, a source file hello.c will generate hello.o after compilation. Usually you do not need to worry about these object files — just think of them as intermediate files involved in creating the final executable.
Once the object files (*.o files) are ready, they are all linked together (along with any libraries) to generate the final executable. This step is called Linking.
In a project, the individual source files can be compiled separately into objects (*.o files). Although you do not have to worry about these object files, sometimes it is handy to compile a file first (for example, to make sure there are no syntax errors). Building a whole project can take a lot of time, especially in the case of larger and more complex applications. Therefore, you will probably go through a series of edit-compile-edit-compile-.... loops while a developing the project.
To compile a file, choose the menu item Build->Compile or click on the Compile icon on the extended toolbar. This will compile the active file.
Anjuta has no separate link command, simply because it is not necessary. The build process will compile all the source files and link them together along with the libraries. The build command will note recompile those files which are already up-to-date (this is called the dependency check). If you have already compiled all of the files individually, then the only thing the build step performs is the link. If you have already built the project and no dependent file has been modified, even the link stage will be skipped.
So how exactly does the dependency check influence the project development? If you have modified a file, then all of the source files that depend on the modified file are recompiled. All files (not only the object files and executable) in the project are checked for these dependencies during the build process. If it is found that a particular file is dependent on some other file which has been modified, then that file will be re-generated.
Since you have now got a rough understanding of the value of the dependency check, can you imagine how your life (as a programmer) would be if it had not been there? If you cannot answer just yet, then will find out when you start developing big projects!
Build->Build will build all of the files in the src (source) directory, and generate the executable. Build->Build All will build the whole project — all of the subdirectories (including src), are built recursively.
To build the tarball distribution of the project choose Build->Build Distribution. This will create a tarball (*.tar.gz) and put it in the top level project directory. Copy the file to a safe place for distribution.
Choosing the menu item Build->Install will install the generated application on your system.
You must be logged in as root to perform a system-wide install. Also note that for a GNOME application to use the pixmaps in the project, it must be installed as a system-wide application. Otherwise, when the application is executed in your project, there will be lots of "pixmap not found" errors.
To run the configure script found in the top level project directory, choose the menu item Build->Configure. The script will determine the system configuration and create some of the files required to perform a build (such as Makefile and config.h). This is necessary because the application may depend on specific configuration of some of these options.
Until you run configure, you cannot start building the project.
The configure script is (usually) run only once at the beginning of the first build process — for example, just after you have extracted a source tarball of a project distribution. After that, configuration is automatically handled by the subsequent build processes. If you have used the Application Wizard to create the application, then you will not need to run configure separately: the wizard will run it as a part of the project generation process.
You can also supply additional options to the configuration script. After choosing the Configure menu item, a dialog will appear to prompt for additional options.
Enter any options (or leave it blank to accept the defaults) and click OK. To find out the options available to the configure script, enter --help in the option entry box and click OK. The options will be displayed in the Message window.
There is no requirement to run configure only once. It can be run at any time, usually when the configuration options need to be changed. One thing to note is that, if the config.h file in the top level directory is changed, running configure again will not overwrite it.
Auto generation consists of two steps: running automake and then running autoconf. If an executable autogen.sh script is found in the top level project directory, this file will be executed instead of the two steps. Like configuration, auto generation is automatically handled by the build process. It can also be run in cases where it is difficult to configure the project (such as lots of errors reported due to mis-synchronization after modifying lots of build files).
Unlike configuration, auto generation does not need to be run even once — in fact, it does not need to be run at all! The option is available because it can be handy in some circumstances.
Choose the menu item Build->Auto generate to auto generate the project.
This option cleans the project and leaves it in a state that requires Build All to be performed. It deletes all of the files generated by the build process, including all object files (*.o files) and the executable(s) in the src directory (and other directories).
Choose the menu item Build->Clean to clean the project.
There is not a great deal to say about Clean All (which might also be called Clean distribution, or clean dist for short). It cleans the project and leaves it in a state that requires Configure and Build All to be performed. It deletes all of the files generated by the build processes, including all the object files (*.o files), executable(s) and Makefiles. In other words, it leaves the project as though it has just been extracted from a distribution tarball.
Choose the menu item Build->Clean All to completely clean the project.