The K Desktop Environment

Chapter 8. Projekte

8.1. Projekttypen

8.1.1. Programme

KDevelop erzeugt standardmäßig Projektdateien mit der Dateierweiterung .kdevprj. Diese Datei enthält alle Projektinformationen, sodaß Sie vorsichtig sein sollten, sie nicht zu löschen. Die Datei wird im Hauptverzeichnis des Projekts gespeichert und muß zum Laden des Projekts geöffnet werden. Die Projektdatei enthält alle Informationen ihrer Dateien wie Dateieigenschaften, Installationspfade, Distributionsstatus und die Compileroptionen (CXXFLAGS). Das Setzen von Dateioptionen erlaubt Ihnen anzugeben, wohin die Dateien installiert werden sollen.

Mit dem KAppWizard können Sie ein neues Applikationsprojekt nach dem gewünschten Typ anlegen. Zur Zeit generiert der KAppWizard vier verschiedene Arten von Rahmenapplikationen:

  • eine SDI-(Single Document Interface, Einzeldokument-Schnittstelle) KDE-Applikation inklusive Menüleiste, Werkzeugleiste und Statuszeile. Dieser Typ enthält alle Elemente zur einfachen Erweiterung zu einer vollständigen KDE-Applikation. Der Programmrahmen verwendet bereits Statuszeilen-Hilfenachrichten, wie sie aus kommerziellen Produkten bekannt sind und wie auch KDevelop sie verwendet. Aus Sicht des Programmierers ist dieses Rahmenprogramm an das MVC (Modell-Ansicht-Controller) Konzept durch Aufteilung des Codes in drei Klassen ausgelegt. Dieser Applikationstyp bietet bereits eine logische Strukturierung zur Erstellung von Anwendungen mit einer graphischen Benutzerschnittstelle.

  • eine KDE-basiertes Rahmenprogramm. Dieser Applikationstyp bietet die größte Flexibilität für diejenigen, die ihr Programm von Grund auf entwickeln möchten, kann aber auch als Ausgangspunkt von Wizards und Modulen verwendet werden.

  • ein rein Qt-basiertes Rahmenprogramm. Für Entwickler, die nur die Qt-Bibliothek als graphische Benutzerschnittstelle verwenden möchten, bieten wir dieses intelligente Rahmenprogramm, um die Applikationsenwicklung zu vereinfachen. Da die Qt-Programmierung vollständig unterstützt wird, sollten Sie keine Probeme bei der Erstellung vollständiger, rein Qt-basierter Applikation haben.

  • ein C++ Rahmenprogramm. Dieser Applikationstyp ist für die Entwickler gedacht, die ein Terminal-basiertes C++ Programm schreiben möchten. Enfernen Sie einfach die Zeile mit "Hello World" in der main()-Funktion und konstruieren Sie Ihre Klassen wie gewöhnlich mit KDevelop.

  • ein C-Rahmenprogramm. Dieser Programmtyp ist auf das Vorhandensein eines C-Compilers beschränkt.

Zusätzlich bietet sich KDevelop an, um mit bereits existierenden Projekten zu arbeiten. Diese können jede Option haben, die der Programmierer selbst in configure und Makefiles gesetzt hat. Soweit es die Ausführung und den Erstellungsprozess betrifft, sind zur Zeit nur die gleichen Strukturen wie bei der Erstellung von Rahmenprogrammen erlaubt. Erzeugen Sie ein eigenes Projekt mit dem Applikations-wizard und fügen Sie Ihre Dateien dem Projekt hinzu, um die Bearbeitung mit dem Klassenbrowser zu ermöglichen.

Um den Erstellungsvorgang sicherzustellen, muß Ihr Projekt alle Quellcodes in einem Unterverzeichnis bereithalten, das dem kleingeschriebenen Projektnamen entspricht; die Ausführung der Binärdatei ist ebenfalls auf den Namen des kleingeschriebenen Projektnamens beschränkt.

Beachten Sie, das KDevelop selbst keine Informationen in die Makefiles oder Konfigurationsdateien schreibt - Sie sind für das Verhalten des Projekts vollständig selbst verantwortlich.

8.1.2. Bibliotheken

Ein allgemeiner Projekt-Typ zur Erstellung von Bibliotheken ist zur Zeit nicht verfügbar. Andererseits ist es jedoch nicht unmöglich mit KDevelop Bibliotheken zu erstellen. Hier erhalten Sie ein paar Richtlinien und Anleitungen:

  • Wann immer Sie in Ihrem Projekt-Unterverzeichnis ein weiteres Unterverzeichnis erstellen, das Quellcodes enthält, wird KDevelop daraus eine statische Bibliothek erzeugen. Das bedeutet, das statische Bibliotheken grundsätzlich schon durch das Projektmanagement unterstützt wird, um die Projektdateien übersichtlicher zu sortieren. Beachten Sie, das die statische Bibliothek später ein Teil der Binärdatei wird und daher nicht installiert wird.

  • Um eine dynamische Bibliothek zu erstellen, können Sie ein weiteres Projekt-Unterverzeichnis anlegen. Die Quellcodes, die sich in diesem Unterverzeichnis befinden, werden dem Projekt hinzugefügt und sind daher in der Klassen-Ansicht as Hauptklassen verfügbar. Um eine dynamische Bibliothek zu erzeugen, bietet Ihnen das KDevelop Programming Handbook im Anhang eine Schablone zur Erstellung der entsprechenden Makefile.am an. Wenn das Makefile des neuen Unterverzeichnisses dem configure.in Skript hinzugefügt wurde, müssen Sie nur noch "Autoconf und automake" und "Configure" ausführen, um die Makefiles zu erzeugen. Die Erstellung selbst ist jedoch nur möglich, indem das Erstellungsprogramm aus dem Unterverzeichnis aufgerufen wird, da KDevelop die Erstellung aus dem ursprünglichen Projekt-Unterverzeichnis aufruft. Eine weitere Möglichkeit, eine dynamische Bibliothek zu erstellen wäre, die Makefile.am des ursprünglichen Unterverzeichnisses an die Schablone des Programmierhandbuches anzupassen, indem Sie die Regeln zur Projekt-Modifikation beachten, die im Abschnitt Project Hacking beschrieben werden.

  • Um eine dynamische Bibliothek zu installieren, müssen Sie den KDE-Datei-System Standard beachten, wie er im The KDevelop Programming Handbook beschrieben ist.

8.1.3. Mehrere Zielobjekte

For some projects, the facilities of KDevelop at it's current state will not last. Those are projects that include multiple targets like packages containing several applications. As commands like "Execute" require that only one target is build by the developer, those types of projects are only supported in the way that you have to write your own entries to the Makefile.am's and creating your directories for the additional libraries or binaries to build. Nevertheless, a build-process always invokes your make-program independent from what actually the targets are; so these functions still can be used (with the restriction that the build is invoked from the main project subdirectory).

Another way to still work with this type and to still have access to the binaries themselves are creating empty projects and move their subdirectories in conjunction with the project files to the directory containing all sources later. Then you could load each target independently by its project file; this also allows executing and debugging the target.

Multiple binaries or libraries within the main project subdirectory are possible with following the rules explained in section Project Hacking and the following guidelines for editing the main project's subdirectory Makefile.am (all modifications outside the KDevelop write area):

  • add your target to the bin_PROGRAMS if it is an executable

  • add your library declaration line if it is a shared library

  • add the same declarations like the original project binary is build:

    • newtarget_METASOURCES

    • newtarget_LD_FLAGS

    • DISTCLEANFILES

    • copy the messages: entry for the original binary and replace target_SOURCES with newtarget_SOURCES, target.pot with newtarget.pot

  • add your sources like the KDevelop write area contains outside the write area for your binary or library

  • for installing static libraries, create the library with KDevelop's auto-creation inside subdirectories. Then modify the Makefile.am outside the write area according to the needed settings