Coding with KDevelop

Zoltan Padrah edited this page Aug 25, 2012 · 1 revision
Clone this wiki locally

This page should help people to set up development environment for KTechLab 0.4 by using KDevelop.

Table of Contents

Installing KDevelop

Ubuntu 10.04 LTS (Lucid Lynx)

By default in the repositories of Ubuntu 10.04 only KDevPlatform 0.9.96 can be found [1] and as of the beginning of June 2010, KDevelop is not available.

There exists a PPA repository for KDevelop here. After adding this repository, KDevelop 4.0 and KDevPlatform 1.0 will be available as installable package.

In order to use GIT, the package kdevelop-plugin-playground-git has to be also installed. This plugin is not yet feature-complete. Due to this, it cannot be used efficiently.

Needed software

  • kdevelop4
  • git
  • git-gui

Setting up git

There are more cases which need special treatment, and also there are some limitations of git gui. Due to this, please check if the following conditions apply:

  • you intend to access password-protected repositories
    • by default, Read/Write access on SourceForge requires this; the alternative is key based authentication
  • the port used by GIT protocol (9418) is blocked by a firewall, while SSH port is not
If none of the above applies to you, then skip to 3.1B, setup without password, else proceed to 3.1A, setup with password-based authentication.

A: Setting up git gui for password-based authentication.

The problem that complicates the setup procedure is related to the password input on some systems. Ubuntu 10.04 and debian testing and unstable is known to be affected. git gui, when not started from a terminal, it cannot ask for a password, so it remains hung. If it is started from a terminal, then it asks for password in that terminal. See bug reports:

on launchpad

at debian

A simple workaround is to start git gui from a terminal, but doing this is not optimal from usability point of view. A better workaround is to use ssh-askpass-gnome, or possibly other, similar program; see the bug reports.

The workaround follows:

1. install ssh-askpass-gnome, if it isn't already installed

2. create a script or launcher for starting git-gui, with the contents:

 #!/bin/sh
 export SSH_ASKPASS=ssh-askpass
 git gui

3. set executable permission for that script

4. start git gui by using that script

Proceed to step 3.3, Creating a new repository.

B: Setting up git gui without password-based authentication

In this case, git gui can be started in any way, it doesn't matter.

Creating a new repository

Having git gui started, select "create new repository"

400px

Select a location for the repository. This will be also the location of the kdevelop project; the folder can be moved without any problem later.

400px

Select create.

Adding remote branches

Here is the main window of the git gui:

Select from the menu: Remote -> Add

Based on your needs, see the introduction at step 2, the following locations can be added:

For case B, read-only, anonymous access, the following repositories are available. If you are not a KTechLab project member at sourceforge, use these:

 git://ktechlab.git.sourceforge.net/gitroot/ktechlab/ktechlab
 git://ktechlab.git.sourceforge.net/gitroot/ktechlab/ktl-alonzotg
 git://ktechlab.git.sourceforge.net/gitroot/ktechlab/ktl-j_ohny_b
 git://ktechlab.git.sourceforge.net/gitroot/ktechlab/ktl-zoltan_p

For case A, Read/Write access or no GIT port available, with authentication, the general form of the location is:

 ssh://USERNAME@ktechlab.git.sourceforge.net/gitroot/ktechlab/REPONAME

This means:

 ssh://USERNAME@ktechlab.git.sourceforge.net/gitroot/ktechlab/ktechlab
 ssh://USERNAME@ktechlab.git.sourceforge.net/gitroot/ktechlab/ktl-alonzotg
 ssh://USERNAME@ktechlab.git.sourceforge.net/gitroot/ktechlab/ktl-j_ohny_b
 ssh://USERNAME@ktechlab.git.sourceforge.net/gitroot/ktechlab/ktl-zoltan_p

Where USERNAME is your username at sourceforge. Note that you need to be a member of the project, with git access, in order to use these URLs.

Fill in the name and location for the repository, select a further action and click Add. Repeat for all the repositories you want to add.

In the case of SSH access, if fetch immediately is selected, you will be asked for a password.

Fetching repositories

After setting up the remote repositories, if you haven't fetched the repositories when added them, it's time to fetch them now. Select Remote -> Fetch from -> REPO_NAME, where REPO_NAME is the name you given to the repository in step 2.3. Depending on the configuration, you might be asked for password.

Creating local branches

For some reason, in some cases, git gui has to be restarted before it can see the remote branches. If in the dialog for creating local branches, no remote branches are listed, you need to close git gui, start it again (possibly by using the created shell script) and select the previously created repository.

In order to work on the code, local branches should be created. Such branches can track remote branches, from other repositories. This way the changes on the remote branch can be easily downloaded to the local repository.

In order to create a local, tracking branch, select Branch -> Create... from the menu, at Starting Revision select Tracking Branch. Next select the branch which you want to work on, and the name for the local branch.

400px

Notable branches are:

  • ktechlab repository: in sync with SVN, including branches
  • ktl-j_ohny_b repository:
    • master: same as ktechlab master
    • kde4-port: the upcoming 0.4 version, for Qt4 and KDE4
    • kde4-port_prebeta8: same as kde4-port, but uses older kdevplatform libs
    • kde4-ktlproject: initial implementation of project management for kde4-port
    • routing: initial implementation of connector routing
  • ktl-zoltan_p repository:
    • master: same as kde4-port
    • simulationmananger: inital implementation of the simulator
    • testing-1: initial implementation of math testing code
Generally, it's recommended to use the kde4-port branch.

Checking out the branch of interest

The check out operation sets the contents of the repository to the files from a given branch of the repository.

Select Branch -> Checkout... and select the branch you want to work on.

400px

After this operation, the "current branch: " line in the git gui should change.

If an error appears, saying that "file level merge required", open a terminal, change the directory to the repository, and change manually the branch: "git checkout <branchname></branchname>". After this, checkout in the gui should also work.

Setting up user name

Finally, for the commits, the user name and email address should be set up.

From Edit -> Options... , complete the user name and email address fields.

Now the git repository is set up and KDevelop can be used to edit the code.

Committing can be done from git gui: first, select an unstaged file, then in the menu perform Commit -> Stage To Commit in order to set it staged, enter a commit message and click Commit.

Setting up kdevelop4

Create a new project

Select Project -> Open/Import ... and navigate to the git repository.

400px

Select the CMakeLists.txt file, and click Next.

Give a name to the project and click Finish.

A cmake configuration dialog appears:

400px

Select the desired options; mostly the installation prefix is of interest, as it should be writable to the user.

Building the project

Click on the Build Selection button on the toolbar. The project should be configured and built. In some cases, dependencies might be missing, but it shouldn't be a big problem.

Installing the application

Due to the way kdevplatform handles plugins, KTechLab has to be installed, in order to detect its plugins. Installation should be done to a location where the user has writing permission. This can be set at Project -> Open configuration..., and at CMake tab, give value to the variable CMAKE_INSTALL_PREFIX. This way the program will be installed to a writable location.

400px

Select Project -> Configure Selection and Project -> Build Selection; finally Project -> Install Selection.

Running the application

Select Run -> Configure Launches.. from the menu.

450px

Enter a name, click on the Executable radio button, and selec the path of the installed ktechlab executable. Click OK.

Next, open a terminal and enter the commands:

 KDEDIRS=/CMAKE_INSTALL_PREFIX/:$KDEDIRS kbuildsycoca4

where CMAKE_INSTALL_PREFIX in the prefix used for installation.

Also

 cp CMAKE_INSTALL_PREFIX/share/mime/packages/ktechlab.xml ~/.local/share/mime/packages/
 update-mime-database ~/.local/share/mime/packages

where CMAKE_INSTALL_PREFIX is the same as above. The first command is needed to make ktechlab to find its plugins, while the following two are for telling ktechlab to open its files (.circuit, .flowcode, .microbe, .ktechlab).

Finally, clicking the Execute button on the kdevelop toolbar should launch ktechlab. One should be able to open .circuit documents with ktechlab.

Running the unit tests

This is not a trivial problem, as the unit tests need to find their plugins, but they are not installed, as the main application. In the following, a hack is described that allows running the tests under kdevelop, but the tests cannot be run directly in a debugger, because shell scripts are executed instead of the real application.

Create a shell script with the following content:

 #!/bin/sh
 export PATH=~/usr/bin:$PATH
 export LD_LIBRARY_PATH=~/usr/lib/kde4:~/usr/lib:$LD_LIBRARY_PATH
 export XDG_DATA_DIRS=$HOME/usr/share:$XDG_DATA_DIRS
 export QT_PLUGIN_PATH=~/usr/lib/kde4:$QT_PLUGIN_PATH
 export KDEDIRS=~/usr:$KDEDIRS
 kbuildsycoca4
 update-mime-database $HOME/usr/share/mime
 $@

This script supposes that you have KTechLab installed in ~/usr/. It sets up several environmental variables, then updates the application and mime cache, and finally it launches the application given by its parameters.

In KDevelop, select Run -> Configure Launches..., there add a new launch configuration. Select Executable in the dialog, and enter the path of the above presented shell script, for example /home/user/usr/bin/my-lancher.sh. As arguments, pass the built tests case application, for example /home/user/projects/ktechlab/build/tests/simulator/basictest.shell

Click OK and execute the newly created launch. It won't be launched very fast, but at least it will work. The problem is that this way the test case cannot be debugged, because gdb doesn't know how to deal with shell scripts. Alternatives are using the terminal, and setting up the environment manually, or create some logic inside the test cases that let them load the plugins autonomously.

References

[1] http://packages.ubuntu.com/lucid/kdevplatform1-libs