The K Desktop Environment

Chapter 8. Proyectos

8.1. Projecttypes

8.1.1. Programas

KDevelop creates a projectfile with the .kdevprj ending. This file contains all your project information, so be careful not to delete it. It is stored in the project's base directory and has to be opened to load the project. The projectfile keeps all information for your files like the file properties, install path, distribution status and compiler options (CXXFLAGS). Setting file properties allows you to keep track of where the files should go.

With asistente de aplicaciones , you can create a new application project according to your choice of application type. For now, KAppWizard generates four kinds of frame applications, as:

  • a single document interface (SDI) KDE -application including a menubar, a toolbar and a statusbar. It contains basic control resource management to allow extending the frame application into a unique KDE application. The application frame also contains statusbar help messages as known from commercial products just like KDevelop itself. From the programmer's point of view, it is based on three application-specific classes leaning on the MVC-concept (Model-View-Controller). Technically, the base classes may not be viewed that way, but it's construction is at least created most logical to create applications with a GUI .

  • a KDE -based application frame window. This application type offers most flexibility to those wanting to develop their program from scratch, but can also be used as a basis for developing wizard applications or modules.

  • a Qt-only based program framework. For those programmers who want to use the Qt-library as the GUI interface alone, we tried to offer you a smart framework to support your application development. As Qt programming is fully supported, you should have no problems to create a full-functional application by using Qt only.

  • a C++ program framework. This application type is intended for those wanting to write a terminal based C++ program. Just remove the "Hello World" line in main() and construct your classes the same way with KDevelop as for KDE applications.

  • a C program framework for C programmers. This is as well a terminal based application but only uses the C compiler.

Additionally, KDevelop enables you to work with already existing projects. Those can have any options set by the programmer himself by configure and Makefiles. As far as the execution and the build-process is concerned, the current state only allows the same structure as for the other baseclasses. Create a custom project with the application wizard and add your files to the project to allow scanning by the classbrowser.

To ensure the build process, your custom project has to have all sources in a subdirectory matching the lowercase name of your project; the execution of the binary is also restricted to this lowercase project name.

Mind that KDevelop does not write any information into Makefiles or configuration files. You are responsible for any project behavior and build settings yourself.

8.1.2. Libraries

A general project-type to create libraries is not available at the moment. Anyway, building libraries is not impossible with KDevelop. Here are a few guidelines and workarounds:

  • Whenever your project subdirectory gets another subdirectory that contains source files, KDevelop will build a static library of these. That means static libraries are already supported by automatic creation in order to sort project sourcefiles. Mind that the static library is part of the binary later and won't get installed.

  • to create a shared library, you have the option to create another project subdirectory. The sourcefiles that are created in this subdirectory are included in the project and are therefore available in the classviewer as root classes. To create the shared library, the KDevelop Programming Handbook offers a Makefile.am template. If the subdirectory's Makefile is added to the configure.in script, you only have to run "Autoconf and automake" and "Configure" to create the Makefiles. The build instead is only possible from a make-command within the subdirectory, as KDevelop invokes the build from within the original project subdirectory. Another possibility to create shared libraries is changing the Makefile.am of the original project-subdirectory according to the template in the Programming Handbook by hand following the rules for project modifications explained in chapter Project Hacking.

  • for installing a shared library, you have to watch the KDE-File-system Standard as explained in The KDevelop Programming Handbook

8.1.3. Multiple Targets

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