Perl has become popular as a text processing and system administration language. In the beginning of the World Wide Web, CGI scripts written in Perl were a widely used method to create dynamic web pages from databases. Today, this method has been replaced mostly by the mod_perl plugin for the Apache web server. Among Perl's strengths are its built-in support for advanced regular expression matching and its rich archive of freely distributed modules.

For more information see the Comprehensive Perl Archive Network (CPAN) website.

Python shines by the elegance of its class system and the ease and flexibility with which external libraries can be wrapped in a way that they appear like standard Python classes and functions. In contrast to Perl, Python has a clear and concise embedding API, which makes it the language of choice for making C and C++ programs scriptable.

PHP was invented as a language directly embeddable into HTML pages and consequently has its main uses in delivering dynamic content in the web.

CORBA (Common Object Request Broker Architecture) is an attempt to let computer applications work together over networks. It was devised by the private, vendor independent OMG (Object Management Group) standards comittee.

CORBA-based programs use the IIOP standard protocol to communicate. Implementations based on IIOP are available on a wide variety of operating systems, programming languages, and networks and are thus highly portable.

The main drawback of CORBA is its rather low speed. While this may be tolerable in networks, it is a real hindrance for inter-application communications in a non-networked environment such as KDE running on a single computer.

Another evolution on UNIX-like scripting is the DCOP protocol which was devised for communication between KDE applications to overcome the limitations of CORBA.

DCOP stands for Desktop Communication Protocol and is implemented as a simple IPC/RPC mechanism built to operate over sockets. In effect this provides facilities similar to the traditional UNIX pipe mechanism.

Traditional shell scripting is based on fairly small tool programs which were designed to work on a strictly textual basis. DCOP allows elaborate graphical programs to communicate with each other in a quite similar way. This enables e.g. a KDE program to send messages to another KDE program, or receive data from it for its own purposes.

There are drawbacks, however. To use DCOP a program must be designed to contain a special DCOP interface. And the DCOP communication process runs somewhat slowly (although a lot faster than CORBA). But it returns much of the power and flexibility of UNIX scripting to high-level programs which are based on a graphical user interface.

For more information, see the DCOP: Desktop COmmunications Protocol paper or The DCOP Desktop Communication Protocol library API reference of the KDE dcop library.

A tool which takes care of recompilations is make. It keeps track of all work using a set of rules which describe what to do in case some piece of information (usually a source or object code file) was changed. All rules belonging to a certain project are stored in a so-called Makefile which is processed by make any time you want to update your work.

Each rule consists of several building blocks, namely

Basically the make command will read the rules one after another, check each file in the dependency list of a given target and make this target anew if any one of these files has changed, using the commands listed in that rule.

There are several additional possibilities to control such a make process, and a Makefile can thus grow very complex. We cannot go into the details here. However, we recommend that you make yourself accustomed to the syntax of make. Even if you do not normally use it directly, an understanding of the fundamentals of the build system can be useful. See the “GNU Make Manual” for more information.

For more KDevelop specific detail see the Building and Project Management chapter of this manual.

There are several tutorials available, see the references in the Building and project management chapter.

(... to be written ...)

(... to be written ...)

(... to be written ...)

(... to be written ...)

(... to be written ...)

(... to be written ...)

(... to be written ...)

Projects created with KDevelop's Automake Manager make it very easy for developers to use the GNU standard development tools. They provide

For developers who enjoy the flexibility and feel of Qt™'s qmake system, KDevelop offers the ability to handle qmake based projects (.pro files) within the GUI.

For more information on the QMake project manager see the “qmake User Guide” which should be included in your distribution or have a look at the TROLLTECH Documentation home page where you may find the QMake documentation of your “Qt C++ GUI Application Development Toolkit” version.

Java™ developers may want to use the Apache ANT project manager for their projects. To set up a new Ant project in KDevelop select Project->New Project...->Java->Ant Project->Application.

For more information see The Apache Ant Project home page.

If you prefer to maintain your own Makefiles for your project you may use the custom project option of KDevelop. This may be feasible in unusually structured projects or if you want to retain full control over the make process.

Yet, if you do not really need the extra flexibility and control of the custom project manager you should consider Automake Manager or one of the other project managers, because they considerably ease the program building and distribution processes.

The distribution of your applications does not require the end-user to have anything different installed other than

which at least for C++ applications is most often the case. But you can as well distribute binary packages of your application. In either way, the end-user of your product does not need KDevelop installed.

For giving away your sources, we advise to include the project file of KDevelop as well. This makes it very easy for other developers—if they use KDevelop—to work with your sources.

For projects where several developers, maybe working on different places, are involved, this should be the case anyway. So you can ensure consistency of the Makefiles to not run into trouble.

Especially on multi language applications, translators won't actually work with the source code, except in cases that require correction for enabling translation support.

Before entering the compile sequence you must make sure all libraries and tools are available to the make system. To accomplish this some environment variables need to be properly set. The actual steps to be performed depend on the console shell you use.

If you want compile and install KDevelop on a FreeBSD system follow the normal instructions but after

you must make the Berkeley specific include files and libraries available to the compiler. This is done through the CXXFLAGS environment variable:

db41-4.1.25_1       The Berkeley DB package, revision 4.1

Most of these tabbed configuration dialogs provide a set of Add, Edit, and Remove buttons to the right of some list field. Use these to change the listed entries or add your own.

If you click one of the Add or Edit buttons you will be shown an Add Documentation Entry dialog like this (deliberately filled in by an example):

---

Adding or changing a documentation entry

---

Local and Remote Documentation.  The KDevelop documentation tree may access local (system internal) documentation files as well as remote (external, mostly accessible via the web) ones. You only need to enter the proper URL addresses in the Location field. (In fact, most predefined entries in the documentation tree at initial KDevelop start-up consist of links to external documention.)

You may at any time change from remote to local documentation (if you e.g. downloaded the files into your system) and vice versa. Just alter the URL accordingly as shown below.

Predefined File Selections.  In some cases when you called the file selection dialog from Add Documentation Entry you may find the display of available files limited by a preset Filter field (located at the dialog bottom). This may e.g. read “*.xml *.dcf” in the case of changing the Qt™ documentation files. If you are unsure about the files you need, best stick to such predefined selections.

The General tab of the Documentation Tree configuration page contains information to access the basic documentation sets needed for KDE programming. Accordingly there are three dialog groups:

---

Setting up KDE basic documentation sets

---

Qt Documentation Collections

Normally KDevelop will fill this in on its first start-up. It looks for standard documentation files in the Qt™ installation directory. The table to the left lists the files KDevelop found by their standard title and URL address.

If you have a non-standard installation, either there will be no information listed at all or the addresses will possibly point to improper locations (e.g. to another Qt™ installation available in your system). You may adjust the entries using the buttons to the right of the list field.

Note

Pressing the Add or Edit to change a Qt™ list entry will pop up a slightly different dialog:

---

Adding or changing a Qt™ documentation entry

---

Normally KDevelop will use the titles already provided by the installed Qt™ documentation. Hence the Title field will be grayed and inaccessible when this Add Documentation Entry dialog starts up. If you want to use your own title text in the documentation tree of KDevelop you must first check the Custom title field. This will provide access to the Title field contents where you then may fill in any text you like.

KDE API Documentations

The other two lists on the General documentation tree configuration page concern API documentations provided by the KDE system.

In short, such an API documents the interface to certain library functions. There are two common ways to produce an API documentation from the sources, namely the older one using the KDE KDoc application and the far more versatile using the externally provided Doxygen tool.

Documentation Generated by Doxygen.  KDevelop will have filled in a link to the current KDE Libraries API, provided it found one at installation time. There are two basic ways for KDevelop to find out:

• Either you provided the configure command with the --with-kdelibsdoxy-dir option when you compiled KDevelop (see the How to Obtain a KDevelop API Documentation chapter).

• Or the configure command did automatically find a Doxygen generated KDE Libraries API in one of several standard locations it knows of.

If KDevelop did not find a valid Doxygen generated KDE Libraries API at its first start-up the Documentation Generated by Doxygen list will be empty.

You may change the entries in the Documentation Generated by Doxygen list using the buttons to the right.

Note

After you first started up KDevelop after a new installation you should in any case check whether the KDE Libraries API had been correctly set up in the documentation tree. It is advisable to have this API documentation at hand because it is basic to all KDE programming.

Tip

The KDE system provides more API documentation than the KDE Libraries API only. You will need additional interfaces information if you want to e.g. include the Kate part into you programs. For this Kate part API for example you should compile and install the KDE Base Libraries API from the sources (using the make apidox and make install commands on the kdebase sources) and then add an entry to the Documentation Generated by Doxygen list like this:

---

Adding a KDE Base API to the list

---

(Of course you should replace the /opt/kde-cvs/ directory in the Location field example with the path to your KDE installation.)

Documentation Generated by KDoc.  There is not much KDoc based API documentation around these days. Hence this list will be empty after the first KDevelop start-up. If you want to add some KDoc based API documentation use the buttons to the right of this list.

The main bulk of KDevelop's documentation tree provides immediate access to structured documentation, local as well as remote ones. You can configure this on the KDevelopTOC Documentation tab of the Documentation Tree configuration page.

---

Providing standard documentations listed in KDevelop

---

There is a special feature associated with this. To illustrate, follow these steps: In the documentation tree find an entry shortly below the Qt™/KDE documentation (e.g. “KDE2 Development Book (kde.org)”). Click on the plus sign next to it. A tree will open where you can quickly navigate to subsequent chapters nested several levels deep, all offline. But if you finally select one of the chapters, KDevelop will in many cases try to access a remote documentation file.

Altering the KDevelop TOC Documentation

There are two ways to alter the KDevelop TOC Documentation. You may change the docuentation tree list, i.e. add to or remove entries from the KDevelopTOC Documentation tab of the Documentation Tree configuration page. Additionally you may point an existing documentation to another base location.

Adding KDevelop TOC Files.  Adding an entry to the KDevelopTOC Documentation tab is fairly straightforward. At first you need a .toc file to some structured documentation following the structure shown above. This is easily constructed using any standard text editor. Then add this file using the Add button on the configuration page.

Removing a KDevelop TOC Entry.  To remove an entry from the KDevelopTOC Documentation tab first select it in the list, then click on the Remove button on the configuration page.

Warning

Think twice before you click on the Remove button!

KDevelop will not only remove the list entry but also delete the .toc file from the directorye. You may want to keep a backup copy if the documentation was valuable.

If the .toc file cannot be removed (i.e. if you have no write access), the entry will remain in the KDevelopTOC Documentation list.

Changing the Base Address of a KDevelop TOC Entry.  If the documentation in an already listed .toc file should be read from another location, tell KDevelop to alter the documentation base address. Select the file in the KDevelopTOC Documentation list, then click on the Edit button.

For historical reasons clicking the Edit button will pop up a different dialog which stems from an older approach to structured library documentation:

---

Changing the base address of a KDevelop TOC entry

---

The Library name field shows the name of the .toc file which was selected in the list. As this is for information only, the field remains inaccessible.

The Documentation path field contains the base address which KDevelop currently uses to access this documentation. Change it to point to the new documentation origin KDevelop shall subsequently use. Then press OK to alter the access.

The remaining Library source path dialog field is of no importance. Just ignore it.

Reverting to the Default Base Address.  KDevelop will not change the .toc file contents. Instead it keeps the current base address in an internal list.

If you want to get the original documentation base address back, use the Default button in this Library Documentation dialog. KDevelop will replace its internal documentation base pointer by the contents of the <base> field in the corresponding .toc file.

(... to be written ...)

---

Providing DevHelp documentation

---

(... to be written ...)

(... to be written ...)

---

Eplicitely adding documentation to the bookmarks

---

---

Adding existing documentation to the bookmarks

---

(... to be written ...)

---

Setting up text search indexes

---

(... to be written ...)

(... to be written ...)

(... to be written ...)

(... to be written ...)

If you set up “MyApp” as in our previous example the Application Wizard should have printed the following messages (we re-arranged the output a bit for readability and you may click on a line to directly jump to its description):

* perl /opt/kde3/share/apps/kdevappwizard/template-kapp/script \
  --author='Your Name' \
  --email='you@you.com' \
  --version='0.1' \
  --appname='MyApp' \
  --dest='/home/devel/projects/myapp' \
  --source='/opt/kde3/share/apps/kdevappwizard' \
  --license='GPL' \
  --licensefile='COPYING' \
  --filetemplates='h,/tmp/kde-devel/kdevelopcDE5Ja.tmp,\
                   cpp,/tmp/kde-devel/kdevelopsRrLab.tmp'
* Making destination directory
* Installing file templates
* Installing license file
* Installing admin directory
* Installing GNU coding standard files
* Installing Docbook template
* Installing project file
* Installing application framework
* Installing application sources
* Finished
* *** Success ***

A Perl Script Called.  As you see from the first line, the Application Wizard did construct a Perl program call from the settings you made in the Create New Project dialog. The called script resides in a directory which was determined from the application type template you selected in the upper part of the Create New Project dialog General page.

In our case this script is located in the /opt/kde3/share/apps/kdevappwizard/template-kapp/ directory. Just replace /opt/kde3/ by the KDE directory on your system.

This Perl script is called with a series of parameters, all marked by “--” prefixes, wherein the Application Wizard put information from the other selections you made in the Create New Project dialog.

The exact series of initialization steps depends on which Perl script was called. If you want to check, just look into the script file the perl command on the first Messages window line did call.

The Application Base Directory.  When the Perl script is run, you get a series of messages of what is about to be done in the next installation step. At first a destination directory will be set up. This is the base directory of your application, just what you got displayed in the Final location line on the Create New Project dialog General page. The script uses the value of the --dest parameter in the Perl command above.

The File Templates.  In the next step the file templates you set up in the Create New Project dialog will be copied to the templates subdirectory of this destination directory. As you can see from the --filetemplates parameter, the templates are submitted in pairs—the suffixes they are used for first, followed by the name of a temporary file in which the Application Wizard has copied the contents of the templates dialog pages. These suffixes will be taken as the filenames of where to store the template texts.

In our example two such template files were installed, namely templates/h for C++ header and templates/cpp for C++ source files.

The License File.  On the General page of the Create New Project dialog you selected the license you want to put your application under. The Application Wizard initiated two actions from this. One was the license indication it put into the templates. The other action causes the according license file to be copied in your application base directory.

The --licensefile parameter tells the Perl script which license text file to copy. In our example the /home/devel/projects/myapp/COPYING file will have been installed in this step.

The Administration Directory.  KDevelop needs a bunch of files to administrate the project. These are put in the admin subdirectory of your application base directory.

Application Wizard creates the admin subdirectory in this step and extracts the standard set of files it needs from the share/apps/kdevappwizard/template-common/admin.tar.gz tarball in your KDE directory.

The GNU Coding Standard Files.  There are several standard files to be distributed with every application which conforms to the GNU coding standard. The Perl script extracts these files from the share/apps/kdevappwizard/template-common/gnu.tar.gz tarball of your KDE installation directory and customizes them according to the information you provided in the Create New Page dialog.

After this step you will find the following files in your application base directory:

The Initial Application Documentation.  Every project you set up will contain an initial DocBook template from where you can start to write your application documentation. The Perl script will in this step have set up doc and doc/en subdirectories of the application base directory with an initial doc/en/index.docbook template and some automake Makefile.am files from which KDevelop can later build help system files.

The Project File.  Up to here most of the more global stuff has been set up, things which more or less are to be found in any KDevelop project. With this step the more application-specific setup processes start. These may vary upon the type of application you selected. Have a look at the actual Perl script the Application Wizard called up for your new application if you want to lookup details. We will continue to follow the example steps listed above.

In the first step of these the KDevelop project management file is copied out of the template directory, where the Perl script resides. In our case the share/apps/kdevappwizard/template-kapp/app.kdevelop file was copied into the application base directory and then customized according to the selections made in the Create New Project dialog.

The Application Framework. Now it is about time that the directory structures and other maintenance files be set up to put the new application in and have it maintained. A so-called application framework will be set up in this step. Its structure basically dependends on the type of application you selected in the Create New Project dialog, but parts of it are common enough to be found in other projects, too.

In our case the following directory structure has been created in the /home/devel/projects/myapp/ application base directory:

All these directories will not kept empty but filled with a series of Makefile and other files KDevelop uses to process the sources of the application. Also some initial icon files for the new application will have been put into the src subdirectory, if applicable. In our case you will find two of them: src/hi16-app-myapp.png and src/hi32-app-myapp.png which both hold standard KDE application icons.

Application Sources Installed.  This framework finally will be used to put the initial source files of your new project in the src directory. The actual files highly depend on the application type you selected in the Create New Project dialog. You will soon see yourself as this is the stuff you will actually have to work on.

Now let us have a look at what the Messages window will contain when the Application Wizard continues to build our example project. If no error occurred during the first pass, the Messages contents will revert to create the local CVS repository.

As before we reformatted the output lines a bit for readability. And we removed some superfluous lines (where the “. . .” dots are).

* cd '/home/devel/projects/myapp' \
  && cvs -d '/home/devel/cvsroot' \
         import -m 'new project' \
                'MyApp' \
                'vendor' \
                'start' \
  && sh /opt/kde3/share/apps/kdevcvs/buildcvs.sh . \
                                                 'MyApp' \
                                                 '/home/devel/cvsroot'
  . . .
* N MyApp/NEWS
* N MyApp/TODO
* N MyApp/README
  . . .
* N MyApp/admin/configure.in.bot.end
* N MyApp/templates/h
* N MyApp/templates/cpp
*
* No conflicts created by this import
*
* *** Success ***

As you see from the first message line, the Application Wizard built another shell command line which conducts the CVS work to be done. At first the shell changes to the newly created application base directory to use it as default in the following steps.

Building the CVS Repository.  In the second command line part the CVS application will be called to import the initial project contents into the wanted repository. Again, the work in detail is commanded by a series of command line arguments to the CVS application call.

The Imported Files.  The CVS application will create the repository and then start to import all files from our /home/devel/projects/myapp directory. It subsequently reports any file which is loaded—this is the contents of the whole bunch of “N” lines following in the Messages window. The N denotes that this file was newly imported into the repository.

Depending on the type of the new application there will be quite a lot of those “N” lines. We truncated the output showing only the first and last three lines as an example.

The CVS Success Message.  CVS always reports when an operation was successfully performed. In our case the “No conflicts created by this import” message was printed, followed by the general “*** Success ***” line as no other operation had to be performed.

Building the CVS Administration Entries.  The CVS import operation is concluded at this point. The repository has been set up and all files we want to be kept were stored in the database. Yet there is more work to do, because the CVS application needs some administration information kept in every directory of the application. It uses this information later to communicate with the cvs root and repository.

If we were working with CVS alone we had to provide a means for CVS to store this information in our working directory. For instance we could check out the files again in an empty base directory in which case CVS automatically would write all administrative operation together with the checked out files.

In KDevelop fortunately there is an easier way. It provides the buildcvs.sh shell script in the /opt/kde3/share/apps/kdevcvs/ directory (again replace /opt/kde with your KDE installation directory), which the Application Wizard called after the CVS application had successfully finished its work.

The buildcvs.sh script mainly will put a CVS subdirectory into each directory of the application framework. Each of these CVS subdirectories will hold three file entries as follows:

All these efforts are necessary because CVS's work is directory-oriented. As CVS previously had stored all files in the MyApp framework, the buildcvs.sh script simply scans every directory and puts the names of all application files it finds into the according CVS/Entries file.

The script runs silently, just closing without any more line in the Messages window when the work was done.

Ctrl-F- Find Ctrl-R- Replace

The conventional search with Edit->Find requires you to specify the full search term before starting. Most of the time, it is much faster to search incrementally. If you click into the edit field labeled ISearch in the toolbar, the search is performed as you type. You will find that often the desired term is already found after typing in 3 or 4 letters.

Both search mechanisms described above are restricted to searching within one source file. An additional tool which allows you to search through a (possibly large) number of files is available through the Search in Files... item in the Edit menu. It is basically a frontend for the grep(1) program.

In the dialog, you can specify which files are searched. There is a number of wildcard patterns available in a combobox. In this way, you can easily restrict the find mechanism to header files. Furthermore, you specify a directory where the search is started. If you check the Recursive box, the search iterates through all directories in the hierarchy below this one.

The search term is in general a regular expression following POSIX syntax. For example, you can use the term "\<K.*" if you want to find all words which begin with the letter K. The following characters are interpreted in a special way:

Backreferences to bracketed subexpressions are also available by the notation \n.

For C++ programmers, as special bonus there are some search templates available for typical patterns. These allow you to search for example all calls of member functions of a certain object.

Once you start the search by clicking on the Search button, it will be performed by an external, asynchronous process. All found items will appear in the view called Grep. You can then jump to the found items by clicking on them. Note that grep scans the files as they stored in the file system. If you have modified versions of them in your editor, you may get some mismatches in the line number, or some found items will be invalid. You can avoid this by saving all files beforehand.

(... to be written ...)

The overall view window contains a tree-list of all the directories in your project that contain program files, documentation or data. Each such directory contains a Makefile.am file and is known in Automake Manager as a subproject. There are three typical subprojects in a KDE-based project as shown in the above illustration:

Note that the doc subproject always has an en subproject, which you can see if you click on the + symbol next to the word doc. That is because the base language of all documentation in KDE is English (en). If your application becomes part of KDE, the KDE translation teams may translate your documentation from English into other languages and the translations will go into other subprojects, such as de (German) or fr (French). The strings in the po subproject may also be translated and stored in other files in po, thus allowing your application to be operated by people who do not know English.

The overall view window serves—amongst other things—as a navigation tool. If you select a subproject in the overall view window, the corresponding details will be shown in the detail view window.

The detail view contains a tree-list of all the files in the subproject currently selected in the overall view as well as the compilation, build and installation rules for this subproject. Thus the two views together can give you access to all the components of your application and all the information on how to compile, build and install it.

Targets. The tree-list in the detail view has two levels. The top level consists of so-called Automake Manager targets and the next level contains lists of files that go to make up each target.

This concept of an Automake Manager target differs somewhat from what a Makefile target usually is. In short:

In both the overall and the detail view you can left-click on the + or - next to a subproject or target name to expand or contract the tree view. If you do that with a subproject in the overall view, it shows or hides the subprojects at the next level down (if any). If you do it with a target in the detail view, it shows or hides the list of files that go into that target.

Opening a File for Edit.  If you left-click on a file name in the detail view, the corresponding file opens up in KDevelop's editing window.

Activating the Automake Manager Toolbar Buttons.  If you left-click on the name of a subproject in the overall view or target in the detail view, the name is highlighted and some toolbar buttons become active in the top part of that view.

Selecting Actions/Popup Menus.  If you right-click on the name of a subproject, target or file, a menu pops up and you can then select actions to perform on the subproject, target or file, such as add a target to the subproject, add a file to a target or logically remove the selected file from its target.

The following sections explain in short terms which operations the menus make available which will pop up on right mouse button clicks in the Automake Manager window. They are meant for overall view only. You will find detailed descriptions of most operations in a later chapter.

The Popup Menu for a File

When you right-click on a file name in the detail view the following menu will pop up allowing you to select one of several operations to be performed on that file. In the illustration below the hi-16app-myapp.png icon file was selected from the Icon data in myapp target of the myapp/src subproject.

The main popup-menu item for a file is to Remove the file from its target (i.e. it will no longer be used to compile, build or install that target). The CVS item offers a variety of CVS operations on the file. The Open With item allows you to open the file with a variety of editors or with any application at all (e.g. you can open the icon file in our example with KIcon). The Perforce item is used for similar operations as in CVS using the commercial “Perforce” version control system.

The Popup Menu for a Target

When you right-click on a target in the detail view the following menu will pop up allowing you to select one of several operations to be performed on it. In the illustration below the myapp (Program in bin) target of the myapp/src subproject was selected.

The Options item for a target only applies to source code files. In the corresponding dialog box you can specify linker flags and paths on which to locate libraries and you can give a list of actual libraries to be linked in to your application. The Create New File item brings up a dialog in which you can set the file name and the type of file to be generated (from a drop-down list). The Add Existing Files item brings up a dialog box in which you can add an already existing file to this target. The Remove item for a target allows you to logically remove the target and all its files from the project structure. The Make Target Active item only applies to targets containing source code files. New files will always be added to such an active target. The Build Target item calls all necessary compile and make operations to build the code for this target only.

The Popup Menu for a Subproject

When you right-click on a subproject in the overall view window the following menu will pop up which allows you to make major changes to the structure of your project and the way it is compiled, built and installed. You can use it to expand or modify the basic project structure that the Application Wizard has created.

The Options item for a subproject controls the way that the subproject will be compiled, built and installed. The dialog box that pops up has tabs for Compiler, Includes, Prefixes and Build Order. The Add Subproject item creates a new directory and skeleton Makefile.am file. The Add Target item pops up a dialog in which you can set the rules for compiling, building or installing a group of files within your subproject. Add Service (... to be written ...) Add Application (... to be written ...) Add Existing Subprojects (... to be written ...) The Remove Subproject item in the popup menu for a subproject is the proper way to remove a subproject. It will adjust the Makefile.am files accordingly. You will also be offered the option to delete all the files (or links) in the corresponding subdirectory. Obviously, this feature should be used with caution. The Build item calls all necessary compile and make operations to build the code for this subproject only. Force Reedit (... to be written ...) Clean (... to be written ...) Install (... to be written ...) Install (as root user) (... to be written ...)

Figure 13.1. Effect of the Configure Script

---

---

Makefile.in into Makefile

prefix = @prefix@
INSTALL = @INSTALL@
build_triplet = @build@
CXX = @CXX@

prefix = /home/bernd/kde3
INSTALL = /usr/bin/ginstall -c -p
build_triplet = i686-pc-linux-gnu
CXX = g++

config.h.in into config.h

/* Define if you have libz */
#undef HAVE_LIBZ
/* The size of a `int', as computed by sizeof. */
#undef SIZEOF_INT

/* Define if you have libz */
#define HAVE_LIBZ 1
/* The size of a `int', as computed by sizeof. */
#define SIZEOF_INT 4

(... to be written ...)

(... to be written ...)