The K Desktop Environment

3.3. Beállítás

The title of this section lets you probably question: Configure ? What has to be configured ? Or who ? Well, assume you have written a program including a Makefile . Then you like to distribute it, but the binary compiled does only run on your system or on systems that are compatible with yours. To support other platforms like different Unix-systems or machines like Alpha's or RISC's, you have to recompile the program. The easiest way would be to copy the source package to the target machine and run make again. But what if the target machine uses another Compiler command or has in some other way a problem to build your binary ? Not to mention more difficult issues like installation paths for your program and documentation- e.g. KDE can be installed in opt/kde/ on one machine, while it is installed under usr/local/kde/ on another. In this case, you would have to rewrite the Makefile each time to ensure a correct compilation and installation of your product.

Fortunately, GNU-tools have even more to provide than that mighty make- the commonly used automake and autoconf packages. It sounds good to hear something with "auto"- seems like something about application design can be done quick and easy, which exactly hits the point.

Automake's purpose is generally to create a so-called Makefile.in from a file Makefile.am which you have to write for your project. This Makefile.am consists of macros which can be interpreted and reduce the complexity that make offers, so a Makefile.am is written safer and quicker than the final Makefile .

Having this said, who is finally creating me my Makefile ? Now, here comes autoconf . Autoconf requires several macro files for the project. That are those Makefile.in 's generated by automake and a file called configure.in, also containing macros. Hereby the Makefile.am and .in's are containing macros that are responsible for the way how to build the software in terms of which sources have to be compiled, which files belong to the package and what name the final binary or library will have after a build. Configure.in on the other hand contains macros for what the final configure-shell script will check for on the system configure is executed. Those could be e.g. the Compiler command, required libraries against which the final binary will be linked, include-files the project needs and their location.

For example you want to write a KDE application. After writing your sources, you want to distribute the program to the user community, and each user has to compile the binary on his own. Then you would write a configure.in file that contains the macros for a KDE -compliant application. That one macro finally expands to a check on the system whether the Qt-library is installed, checks for the Qt-header files, the KDE-libraries and headers etc.

Summary: To create a GNU-compliant application that is portable to different Unix-OS's and machines other than yours, you will need to do the following:

  1. write the sources of your project

  2. write a Makefile.am for each subdirectory, including the main project directory of your project

  3. write a configure.in file placed in the main project directory containing the macros for system requirements

  4. run automake

  5. run autoconf

Then the main work is done. Automake creates the Makefile.in 's, autoconf processes the configure.in and generates an executable shell script called configure. All you then have to do is to execute it with .configure/ and the script will run the checks of your choice. Finally Makefile s will be generated that allow a final execution of make (or gmake) that will process all Makefile s and then you're done.

This seems to be a lot of stuff for writing a small application and much to learn especially how to write correct macros. But even the fact that you provide a compilation on almost all Unix-systems will be worth this work sooner or later. Finally, you only have to do this work once for your project and in case your project's files increase you only have to add the filenames to the macros.

Now, how far does KDevelop support this kind of application development and how complicated does it get for the programmer ? The good news is, that you don't even have to know anything about macros and scripts. All details are hidden behind an easy to use graphical interface doing the work for you. An application is therefore created with GNU tools in a very user-friendly way:

Just generate your application with KAppWizard , by the choice of your application's needs- may it be a pure C++ terminal application or a kind of GUI program using Qt or the Qt/KDE libraries. All work is done automatically and your project already contains the Makefile s that are created by an auto-execution of the GNU-tools and the configure-script.

This is it- you're ready to extend the source of your project, may it be by adding classes , dialogs, translations or documentation, which is also completely automated. Just concentrate on the real work of the developer, which is providing functionality for the final application that you want to create. In most cases, you probably won't come in touch with Makefile s at all when using KDevelop.