The K Desktop Environment

Página siguiente Página anterior Índice general

3. Programas

Ahora que ya ha instalado KDevelop satisfactoriamente, y que las opciones más utilizadas están configuradas, se estará preguntándose si este programa ofrece lo que promete. En este capítulo se le dará una guía sobre como crear programas con las herramientas GNU y sobre la parte que KDevelop juega en el proceso.

3.1 El compilador

El compilador es el programa que, como mínimo, debe estar instalado en su sistema para poder crear programas ejecutables; este programa es el que compila el código fuente, transformándolo en ficheros objeto con los que crea el programa.

Normalmente, lo ejecutaría de esta forma: Abra el editor que suela utilizar - no use un procesador de textos. Escriba algo como lo siguiente para crear el código fuente de su primer programa:

#include <iostream.h>

int main(){

cout << "Hola Mundo" << endl;

}
Bueno, todo lo que el programa hará será imprimir la cadena "Hola Munda" en la salida estandar. En cualquier caso, este es el código del programa a generar, no el programa propiamente dicho. Necesitamos un compilador, en este caso un compilador de C++ como g++. Guarde el código fuente como, por ejemplo, miprograma.c e invoque el compilador con el nombre del fichero (en la consola):

g++ -o miprograma miprograma.cpp
Ahora ya se puede ejecutar el programa. Escriba miprograma en la consola. El programa mostrará la cadena; después finalizará.

3.2 Make y Makefiles

Vale, ya tiene todo lo que necesita: un editor y un compilador. Además puede ejecutar sus propios programas C++... Pero no es todo tan fácil, ¿qué pasa si tiene más de un fichero fuente? Además, ¿Tiene que compilar todos los ficheros cada vez que modifique uno? A medida que los programas se hacen más grandes, se vuelven más costosos y complejos de compilar, ya que tiene que ejecutar todos los comandos y opciones directamente. La solución pasa por crear un fichero con el nombre Makefile (en realidad puede tomar cualquier nombre menos el del programa) en el que insertar todos los comandos necesarios para compilar el programa, por supuesto con unas normas de sintaxis. Si las herramientas make o gmake están instaladas, lo único que tiene que hacer es escribir el nombre de la herramienta en el directorio en el que el fichero Makefile se encuentra (si el fichero tiene otro nombre es necesario pasar el parametro `-f nombrefichero'). En ese momento la aplicación make toma el control y se encarga de la compilación del programa. La aplicación make tiene otras muchas ventajas y puede ser utilizada para muchos propositos. Para obtener una visión más clara de la herramienta, abra la consola y escriba:

man make

o busque "GNU Make" en la ayuda del KDE, en "System GNU Info contents".

At least, you have an insight, why a developer needs the make utility for making it easier to compile his application. Now, writing Makefiles is not only handwork until now, you also have to dig yourself into the whole syntax and options. But here is the good news about KDevelop and any Make-utility: You just have to set the Make-Command in the Configuración del KDevelop dialog, and then you're done. All projects generated with KDevelop will use that Make command to build the target application, and no typing at all. Just hit the buttons on the toolbar of KDevelop, beginning with the one after the second separator line, or choose the desired function for Make in the "Build" menu.

The toolbar and the build-menu then offer the most-common functions that you need to let make do the dirty work:

But this is not the only way how KDevelop works together with make- for KDE applications, there are some things that are special, like creating the message files for internationalization. These functions are also included, so no worry about these things anymore.

Until now, you know about sources, the Compiler and why make is needed. In the next section, we'll discuss how it comes that projects created with KDevelop automatically can be compiled on most other Unix-platforms using the configure- script.

3.3 Configure

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 Makefiles will be generated that allow a final execution of make (or gmake) that will process all Makefiles 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 Makefiles 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 Makefiles at all when using KDevelop.

3.4 Debugging

The following section covers a term that is widely used by developers: Debugging. It means, that, although your Compiler produces the final application, your application may not run or crash during execution due to a so-called "bug" in the code. A program error described by the name of this insect comes from the history of computing; one of the first errors that caused a machine to crash was not obviously a malfunction- bugs were inside the computer which were responsible for it. Therefore, an error not detectable on the first look is called a "bug", so "debugging" means to throw out bugs where they shouldn't be. Now, you don't have to hunt them for real; assuming that today's computers are designed to keep them out by some kind of outer protection. They have to be found inside the code, mostly ending the execution of a program with the message "Segmentation fault". GNU provides another tool called gdb, the GNU debugger. This terminal program allows to watch the internal values of an application and the execution step by step with setting "breakpoints" in the code. Gdb stops the execution every time the program comes to a breakpoint while executing. But like most other tools, the debugger is handled by another program providing a frontend to it, allowing to easily watch values and the setting of breakpoints in the code.

For this purpose, your project's application is by default created with a Compiler option for debugging, thereby storing additional data in the executable to allow the localization of values and lines in the code. As a third-party frontend to gdb, KDevelop makes use of KDbg, the KDebugger. To debug your program, you just have to select "Debug" in the Build-menu or press the according toolbar button displayed by a wheel having glasses over it, signaling that you want to watch the execution.

KDevelop then opens the Tools-window and starts your application with KDbg. The KDbg interface appears inside the Tools-window and allows the usage just like you started it from outside.

In general, the above steps are clearly showing the need of certain steps that a developer has to do when starting to write his own application, and cover issues that are common to all projects. Also, we explained what part KDevelop does for a developer and how it supports the idea of providing an easy way to Unix programming. To get further information about the role and purpose of GNU tools, you should read the documentation provided with them, commonly accessed via the man command or by the "System GNU Info contents" section in KDEHelp.

Página siguiente Página anterior Índice general